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SECTION I 


INTRODUCTION TO LEVEL 64 COMMUNICATIONS 


The Level 64 GCOS Communications Processing Facility enables the user 
- to run MCS COBOL applications that require access thru queues to a communi- 
cations network 
» to run communications subsystems collectively termed VCAM (virtual communi- 
cations access method) and which comprise IOF (interactive operation facili- 
ty) and TDS (transaction driven system). 


The communications processing facility is described in terms of its components, 
- Hardware 
« Firmware 
- Software 
. User applications 


Communications Components 


to URP devices 
MIOS . 
RBF/6 
D ‘ 
C up to 14 lines 
BATCH are C > 
ENTRY . 
D ; 
C up to 14 lines 
; C additional > 
: 
es = ee C up to 14 lines 
additional > 


USER 
APPLICATIONS 


SOFTWARE FIRMWARE HARDWARE 
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HARDWARE 


In addition to standard site equipment, the hardware needed to support a 


communications network comprises, 


Data Communications Controller(s): The DCC is attached to the Unit Record 


Communications Lines 


Terminals 


Processor (URP) and provides the interface 

for the terminals. 

The DCC controls line transmissions in 

assembling and disassembling characters. 

It can support as many as 14 line simul- 

taneities, each of which is a data path 

defined as follows, 

- a two-way-alternate (TWA) line uses one 
Simultaneity 

- a two-way-simultaneous line uses two 
simultaneities. 


The versions of the DCC are, 

- DCC4100 or DCC4901 connectable to the IURP 

~ DCC4200 or DCC4902 and DCC4903 can be connect 
ed to the additional URP. 


Communications lines can be, 

- Local, which is a direct connection by 
cable 

~ Switched, which uses a dial-up mechanism 
to select an available telephone link 

- Leased, which is a private user line 
with supporting modems. 


The line is used as follows, 

- Point-to-point, connecting one terminal 
to the central processor 

- Multipoint, connecting several terminals 
on the same line to the central process- 
OLe 


Transmission can be, 

- Synchronous, ranging up to 19200 bauds 
- Asynchronous, ranging from 50 thru 2400 
bauds and can be any of 4 pre-selected 

speeds per DCC. 


The terminal is the communications device 
for data entry and reception 

It is associated with 

- Terminal type 

- Line procedure 

- Terminal subtype. 


For further details on the network, see 
Section Ve 


Terminal Types & Line Procedures 


Line Procedure Line Procedure 
Terminal A=Asynchronous Terminal A=Asynchronous 
S=Synchronous S=Synchronous 


lavat| 


| TWU/PRULOOL | 


TWU/PRU1003 TTY 
TWU/PRULOOS5 
HL6 2 
HL64 ree oe 
HL66 


VIP7200 oue | 
VIP7700 
VIP7760 ee 
TN300 
BSC = 


= Line procedure 4 Line procedure 1 


VIP7100 


TTY = Line procedure 1 Line procedure 3 = 
VIP Line procedure 3 Line procedure 4 


Terminal Subtypes 
[subtype] abbreviation | meaning 


CASsette 


cassette handler 


levels 62/64/66 


Central Processor Unit 


Cathode Ray Tube screen 


KeyBoard keyboard 


Keyboard Cathode-ray Tube | keyboard and screen 


Keyboard with PRinter keyboard and printer 


PRinTer printer 


F TRMWARE 


Communications firmware is the multiline attachment (MLA) which consists of, 

« A set of common attachments to distinguish line connections 

. An attachment for each of the 3 line procedures to be handled by the unit 
record processor (URP or IURP). 


The MLA functions with MIOS (micro-operating system) for terminal management. 


SOFTWARE 


Communications software comprises 5 major components, 
- BINS, basic terminal network support 

- MAM, message access method 

e VCAM, virtual communications access method 

« CNC, communications network configurator 

« QMAINT, queue maintenance 


Basic Terminal Network Support (BINS) 


BINS is the nucleus of Level 64 communications performing such functions as, 


- Managing physical operations of the network, as initializing the lines and 
transferring data over the lines 


« Allocating communications resources, ieee, allocating terminals to applica- 
tion programs, and vice versa, and sharing lines among application programs 


» Transmitting messages from terminals to program queues and from terminal 
queues to terminals 


« Honoring connection and disconnection requests from terminals, and data 
transfer requests for VCAM subsystems 


- Monitoring constantly network activity such as message switching and error 
logging. 
A detailed description of BTNS is dealt with in Section II. 


Message Access Method (MAM) 


MAM is a distributed queueing access method which operates with BINS to form 
the Message Control System (MCS). 


MAM provides such functions as, 


- Compatibility thru MCS with standard COBOL communications language elements, 
ieee, CD area, ENABLE, DISABLE, SEND, RECEIVE and ACCEPT verbs 


- Access to memory and disk queues, with 2 levels of queue available for input 
- Checkpoint/restart capability for disk queues 

- Allocating queues to application programs 

- Message editing according to terminal type 


- End-to-end protocol between the terminal operator and the application program: 
as provided either by control messages generated by MAM or by Status gener- 
ated by BTNS 


- Communication between process groups, isé., communications load modules, and 
between processes, ise, tasks 


» Multitasking within an application program from 1 thru 6 user processes. 
A detailed description of MAM is dealt with in Section III. 


Virtual Communications Access Method (VCAM) 


VCAM is a distributed access method which allows direct communication between 
communications subsystems and terminals via BINS, or between the subsystems 
themselves. 


The communications subsystems are,. 

- IOF, interactive operation facility 
- RBF/6, remote batch facility 

- TDS, transaction driven system 


An example of such communication provided for by VCAM is the communication be- 
tween TDS and a batch entry utility which allows access to transactions from the 
batch simulating terminals for TDS. 


The subject of IOF and TDS is treated in "User Applications" later on in 
the section. 


Communications Network Configurator (CNC) 


CNC is a utility program for creating a communications environment which in- 
cludes the structure of the network and the way it is to function. This environ- 
ment is described through the Network Description Language (NDL). The set of NDL 
commands for the communications environment is defined by the user to describe 
pertinent aspects of the lines, stations, terminals, queues and correspondents, 
such as BINS, VCAM subsystems and batch programs. This description is then pro- 
cessed by CNC. 


CNC performs such functions as, 
- Checking the syntax of commands 


» Crosschecking description details against information previously established 
in system tables 


- Generating terminal tables and line buffer pools 


- Preformatting a disk queue file, where applicable, on the information 
provided. 


A detailed description of CNC is dealt with in Section V. 


Queue Maintenance (QMAINT) 


QMAINT is a utility program for executing maintenance actions on memory queues 
or disk queues. 


QMAINT performs such functions as, 

- Printing the contents of a queue 
» Displaying the status of a queue 

- Purging a queue 

» Filling a queue with defined data. 
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A detailed description of QMAINT is dealt with in Section VI. 


USER APPLICATIONS 


User applications available thru Level 64 communications are, 
» IOF 

« RBF/6 

- TDS 

- MCS COBOL applications 


Interactive Operation Facility (IOF) 


IOF is a syStem interactive utility which provides the user with the necessary 
tools for program preparation, namely, 


- Creating, updating and deleting source files or subfiles containing data or 
JCL 


- Launching batch jobs from a terminal 
- Scanning and receiving output reports from batch jobs. 


IOF is a system load module. When the user requests connection to IOF, an IOF 
step is launched dynamically by BTNS. An IOF step is launched for each remote 
user working with IOF. The step is terminated on disconnection of the user. 


For further details, see Interactive Operator Facility Manual. 


Remote Batch Facility/6 


RBF/6 is a system utility for executing remote job entry from Level 6 satellite 
processors to a Level 64 host system. Printed output reports can be routed to 
the Level 6 processors. For further details, see the Level 64 GCOS Remote Batch 
Facility Manual, Order No. CQ35. 


Transaction Driven System (TDS) 


The user provides COBOL programs in the form of Transaction Processing Routines 
(TPR). Each TPR can receive a message to process data and generate a response. 


TPRs are linked dynamically to the TDS executive. The advantage of dynamic link- 
ing is that TDS generation is not necessary each time a TPR is modified or added. 


Unlike IOF, TDS occupies 1 level of user multiprogramming. 


For debugging purposes, the TDS version can be executed as a job step with a 
simulated network of batch entry programs functioning as terminals. 


For further details on TDS, see the appropriate manuals listed, 


- TDS Programmer Reference Manual, Order No. AQ57. 
- TDS/64 User Guide, Order No. AQ56. 


» TDS/64 Standard Processor Site Manual, Order No. AQ55. 
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MCS COBOL Applications 


An MCS COBOL program can be either a monoprocess load module or a multiprocess 
load module executed as a job step. The load module is created from COBOL 
compile units (cu) by the Static Linker, see Section III "Linking MCS COBOL 
Programs"'. 


An MCS COBOL program is recognizable either to BINS or to another MCS COBOL pro- 
gram by the input queue(s) from which it receives messages. Conversely, an MCS 
COBOL program recognizes only the output queue(s) to which it send messages; it 
does not recognize BINS or the destination terminal or another MCS COBOL pro- 
gram 


RELATING THE COMMUNICATIONS ELEMENTS 


The following points. summarize the communications package, 


- BINS is a system load module H_BINS residing in the system load-module 
library SYS.HLMLIB and run as a service job, like IOF, which does not 
occupy a level of user multiprogramming. 


« MAM and VCAM are the software support components for user applications and 
communications subsystems. They are -distributed access methods shared at 
system level among BINS, QMAINT, MAM application programs and VCAM sub- 
SyStemsSe 


« CNC is a system load module H_CNC residing in the system load-module library 
SYS. HLMLIB and run as a job step each time a network needs to be generated 
or modified. 


« QMAINT is a system load module H_QMAINT residing in the system load-module 
library SYS.HLMLIB and run as a job step each time maintenance actions are 
required on MAM queues existing on the site. 


- MCS COBOL programs and VCAM subsystems, i.e., IOF and TDS, are load- 
modules residing in a "private" library or a system library and run as 
job steps. TDS occupies one level of user multiprogramming. Each IOF 
user occupies one level of interactive-job multiprogramming. 
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BASIG TERMINAL NETWORK SUPPORT 


During the communications session, BINS performs the following functions, 
+ prepares the communications environment at BINS start-up 
- dispatches events 
« monitors the network thru the site controller 
» processes input/output requests 
* processes messages 
- handles errors 
- performs shutdown procedures 
- performs message-switching 


START-UP FUNCTIONS OF BTNS 


BINS is started by the network control command ST. Each time BINS is run, it 
performs the following functions, 

« restores the network tables 

- initializes and sizes buffer pools 

- initializes the IURP (integrated unit record processor) 

- initializes the VCAM interface (virtual communications access method) 

« initializes the network 


Restoring the Network Tables 


Network tables are stored in one segment created at network generation by the 
CNG utility. These tables are restored each time BINS is started from a copy of 
the communications system segments existing on backing store. Any modifications 
made to the network during a previous session are ignored and only the original 
network description generated is restored. 


The tables concerning MAM or VCAM, and in particular queue pools, are not re- 
stored because they can still be used by the application programs in the absence 
of BTNS. 


Initializing and Sizing Buffer Pools 


BTNS uses buffer pools to execut data transfers over communications lines and 
for network control functions. Ai ‘er pool is created for the exchange of mes- 
sages between terminals and queues. .. ‘3 a set of chained buffer units of fixed 
lengths The number and size of buffer units are specified at network generation 
Each buffer pool occupies a segment no greater than 64K bytes of main memory. At 
Start-up, BTNS creates the segment(s) and initializes the buffer unit chains. 


If VCAM subsystems are to be run, a second buffer pool, the VCAM buffer pool, is 
created to contain messages sent from the subsystems to the terminals. 
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Both buffer pools are either tailored by the user or automatically generated by 
H_CNC according to default values, see GENCOM command in Section V. 


Initializing the TURP 


When system initialization is performed, ILURP firmware is loaded and all the unit 
record devices are initialized. At BINS start-up, a further initialization se- 
quence is required for the following, 

« to prepare firmware tables of the communications lines 

» to enable equipment, such as modems 

« to activate firmware functions concerning communications lines. 


For each line declared active at network generation, the following functions are 
performed as part of IURP initialization, viz, 

» loading the TCT (translation control table) 

- reading, updating and loading the TLT (terminal line table) 

« loading the polling list 

» initializing data-sets (modems) 

« error handling during IURP initialization 


LOADING THE TCT 


The firmware uses the TCT to translate internal code EBCDIC to line code, gener- 
ally ASCII, when sending, and vice versa, when receiving messages. In addition, 
the TCT defines special functions such as, 

» an "erase" character on input 

« end-of-block characters for input and output. 


For each line procedure, there is a separate TCT. 


READING, UPDATING AND LOADING THE TLT 


The characteristics of each line are defined in its TLT which includes, 
« line type, "leased" or "private" 
» automatic connection of the modem 
- half-duplex or full-duplex. 


Certain other characteristics can be modified at network generation by the user, 
€e ge, TOLEN time-out parameter of the LINE command, see Section V, or by the 
field engineer. BINS must therfore read the tables in order to ascertain if any 
modifications are to be made before loading the tables. 


LOADING THE POLLING LIST 


Except for lines using the TTY line procedure, a polling list must be loaded for 
each line. BINS loads into the IURP a list of stations to be polled on the lines 
declared at network generation. 


Whenever BINS requests data on a line, MLA firmware begins polling stations in- 
dicated on the list either in "round-robin" or "linear'' sequence until a station 
replies. Polling recommences at the station defined by the type of sequence used, 
see LINE command in Section V. 


INITIALIZING DATA-SETS (MODEMS) 


At Start-up, BINS initializes the modem at the central processor (CPU) for 
leased and private lines. BTNS requests the starting of the search for the ring 
indicator for each switched line. 
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ERROR HANDLING DURING IURP INITIALIZATION 


If an error is detected on a line during initialization of the IURP by BTNS, the 
system console operator is notified. 


The line is declared as HELD and the system operator can retry the initialization: 
of the line immediately or later on by issuing the RT network control command. 


Initializing the VCAM Interface 


BINS identifies itself as a correspondent of VCAM and accepts any connection 
requests from any of the VCAM subsystems. 


Connection enables exchanges between BINS and the subsystems. These requests 
could have been enqueued earlier, awaiting the start-up of BTNS. 


Initializing the Network 


The final stage in BINS start-up is the launching of network control procedures 
to perform the logical initialization of the network which consists of, 
» initializing the network control interface 
» connecting, if possible, all terminals identified as automatic and assigned 
at network generation 
« activating the BINS dispatcher. 


BINS DISPATCHER 


The BINS dispatcher is responsible for event managemente It activates the appro- 
priate BINS functional component according to the type and source of the event 
that has occurred. These events originate from the network, application programs 
or other system components. 


SITE CONTROLLER FUNCTIONS 


Functions of the site controller are broadly divided as follows, 
- controlling the network 
- Sharing network resources. 


Controlling the Network 


The entities constituting the communications system are, 
- BINS 
« communications lines 
- terminals 
« queues 
- VCAM subsystemSe 


The status of each of these entities is determined by its availability, ieee, 
either "open" or "close", and the parameter values used to describe it at net- 
work generation. The status can be altered thru the network control commands 
and to a lesser extent, by the terminal operator commands, see Appendix F. 


A change in the status of any entity involves updating the communications tables 
and notifying all other entities affected by the change. 
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Activity on communications lines is constantly monitored. The two events which 
cause BINS to take automatic action are, 

» error detection 

« attention notifications. 


ERROR DETECTION 


Any error detected on a line or terminal during message exchange is recorded by 
IURP firmware as an abnormal termination of transmissiom The BTNS dispatcher is 
notified of this event which results in subsequent message retries according to 
the number specified for the appropriate LINE command at network generation If 
the exchange still cannot be successfully completed, the following uctions are 
taken automatically, 
- the appropriate line, station or terminal is closed 
» the network control operator or the system console operator is notified 
- the disconnected terminals are then reported to the program queues defined 
with the BREAK option or VCAM subsystems to which they were currently con- 
nected. 


A line, station or terminal which has been closed, can be reactivated by the RT 
network control command. 


ATTENTION NOTIFICATIONS 


Certain events unrelated to data transfer but concerned with a change in the 
status of an entity, are reported to BINS thru attention notifications. These 
notifications which result in automatic actions are, 


» ring indicator : A search for the ring indicator is begun for all 
switched lines at BTNS start-up. At the outset, all 
switched lines are closed. When a call is made over 
such a line, a ring indicator attention is issued, 
notifying the network control interface to set the 
Status of the line to "open'. This in turn causes 
the resource sharing portion of the site controller 
to begin a log-on dialog with the calling terminal. 


A disconnect line attention is issued when a speci- 
fied time, preset in IURP firmware has elapsed 
without activity on an open switched line. This 
causes the net.ork control interface to, 

- disconnect the terminal on the line 

- close the line 

-~ notify the network control operator. 

BINS then recommences the search for the ring indi- 
CatOre 

The disconnect line condition can only occur during 
the log-on sequence. Once the terminal is logged-on 
to an application, BINS tries to receive data from 
the terminal when no output is pending. If no data 
is entered within the lapse of time defined by the 
TOLEN parameter of the LINE command, then "time-out" 
occurs and the condition is treated in the same way 
as for disconnect line. 


e disconnect line 
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- Station on/station off : When the control unit of a station is turned on, 


the IURP firmware issues an attentions The network 

control interface notifies the resource sharing in- 
terface whether log-on procedures may be accepted. 

Terminals which are declared automatic or assigned 

must be initialized. 

When the station is turned off, the network control 
operator is notified, and each terminal is discon- 

nected. Application programs and program queues are 
also notified of the disconnections. 


Sharing Network Resources 


Network resources are, 


- communications lines 

» terminals. 
These resources are managed by the network resources sharing interface of the 
site controller which oversees their distribution between MCS COBOL applications 
and VCAM subsystems. 


The communications system establishes the link between a terminal and the user 
application. A terminal is reserved for the application to which it is connected 


until the 
nected to 
nected to 


A line is 


connection is broken, in which case, it is then eligible to be con- 
another application. An application can have several terminals con- 
it at any given time. 


not exclusively reserved for any one application. Several applications 


can therefore be connected simultaneously over a multipoint line. A network can 
theoretically be generated to allow all its terminals to communicate with all 
applications sometime during a communications session. 


The two types of connection are, 


» direct connection : For VGAM subsystems, the connection to the terminal is 


directe 


» logical connection : For MCS COBOL application programs, the connection to 


the terminal is logical to allow for the following con- 

ditions, 

- the program can be connected to an output queue whose 
destination terminal is not active 

-.the terminal can be connected to an input queue whose 
associated program is not executing. 
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Sharing Network Resources 


qu 


<q] ™ 
-» terminals Tl and T4 are connected to TDS (VCAM subsystem) 
- terminals T2 and T3 are connected to the MCS COBOL application named COB 
- the terminals have been logged on either automatically or manually 


<q{ m4 


« terminals T1 and T4 have logged off TDS and are now connected to COB 
- terminal T2 has logged off COB and is now connected to TDS 
» terminal T3 remains logged on to COB 


LOG-ON PROCEDURES 


The log-on procedure to be used depends on the type of terminal, namely, 


« general purposeterminal : 


dedicated terminal 


A general purpose terminal can communicate with 
any MCS COBOL application thru a program queue or 
a VCAM subsystem present in the system A program 
queue defined at network generation is available 
to such a terminal as soon as BTNS is started. 
The VCAM subsystem is present in the system if it 
has been declared in the DCTAP command at genera- 


tion, see Section V. 


The request for log-on depends on the line type, 

- for switched lines, a call is placed 

- for leased lines or local lines (multipoint or 
point-to-point), a BREAK signal is sent. 


Connection is established if: 
- the terminal and line are "open" 
- the application or VCAM subsystem is known to 
the system and active 
- all information has been correctly supplied by 
the operator for a terminal declared with the 
CONTROL option in its TERMNL command, namely, 
° user identification, which is checked against 
the system catalog 
° name of the application to which the terminal 
is to be connected. 
- for VCAM subsystems, the number of terminals has 
not exceeded the maximum 


A message other than the BREAK signal sent by a 
terminal that is not connected will be ignored. 
After connection has been established, the BREAK 
signal is only considered if the QUEUE command 
defining the queue to which the terminal is con- 
nected has been declared with the BREAK option or 
if the terminal is connected to a VCAM subsystem 


: A dedicated terminal can log on only to a specific 


application named in the ASSIGN option of the 
TERMNL command at network generation. When the re- 
quest to log on is made, BINS establishes the con- 
nection if the conditions as for the general pur- 
pose terminal have been fulfilled. 


The MIT network control command can alter the 
Status of a dedicated terminal to a general pur- 
pose terminal and vice versa. 


2-07 


automatic terminal 


terminal cluster 


A terminal declared with the AUTO option in the 
TERMNL command at network generation requires no 
operator intervention to establish a connection. 


For general purpose terminals, the connection is 


established as follows, 


with MCS COBOL program(s) when the output queue 

associated with the terminal is enabled and con- 
tains data to be dispatched 

with VCAM subsystems when they request the ter- 

minal. 


For dedicated terminals, the connection is estab- 
lished as follows, 


with the MCS COBOL program when BINS is started 
with VCAM subsystems, only with the TDS version 
when it becomes active; for IOF and ROF, connec- 
tion is established thru the automatic start by 
the site controller. 


This capability is designed for, but not restrict- 
ed to, 


terminals without a log-on capability, such as 
receive-only terminals and central processors, 
to be connected to a program queue 

terminals which cannot be dedicated because they 
are used successively by different users. 


The terminal cluster or multi-terminal station, 
such as the VIP7700, can be defined with one or 
several masters for other slave units attached to 
the same station. This is done by defining conse- 
cutive TERMNL commands with the SLAVE option fol- 
lowing a TERMNL command for which a valid terminal 
type has been specified, see Section V. 


This master/slave concept is solely for the conve- 
nience of logging on which involves the following, 


when the master logs on to an application, all 
its slaves are logged on simultaneously 

if the master is a dedicated terminal, all its 
slaves are dedicated to the same application 

no slave can log on or be dedicated to an appli- 
cation independent of its master. 


LOG-OFF PROCEDURES 


A terminal is logged off in a variety of ways, namely, 
- the terminal is turned off 
e a transmission errer has occurred and a number of retries has been unsSuccess- 
fully attempted 
- an abnormal condition has occurred while BINS attempts to queue a message 
received from the terminal . 
» the terminal is disconnected by the VCAM subsystem to which it was connec- 
ted 
- the VCAM subsystem to which the terminal was connected, has terminated 
- the following operator commands have been issued, 
- HT network control command identifying the terminal to be released 
- DIS terminal operator command issued at the terminal itself; reconnection 
for a dedicated terminal is made thru the mechanism specific to the type 
of terminal. 


PROCESSING INPUT/OUTPUT REQUESTS 


From the point of view of BTNS, messages can be exchanged between the following 
entities, 
- between a terminal and the site controller during the log-on procedure or 
thru the site controller commmands 
- between a terminal and a VCAM subsystem if the subsystem is executing 
» from a terminal to a program queue if the queue is enabled 
. from an output queue to a terminal if the queue is =:nabled. 


Input Requests 


When no output requests are outstanding, the following takes place, 
« for non-polled lines of the TTY line procedure, BTNS requests the MLA, that 
is the LURP firmware, to accept any input 
- for polled lines, the search for input requests is made either in the 
"round-robin" or "linear" sequence. 
The polling sequence is defined for the line by the order in which the sta- 
tions are specified at -network generation or by declaring explicitly the 
polling list thru the POLLIST parameter of the LINE command. This sequence 
can be modified by the MTP network control command. 
When polling finds an input request, the BTNS input request routine directs 
the message according to the application as follows, 
- if the terminal is connected to a queue of an MCS COBOL program, then cne 
of the alternatives occurs, 
° the message is sent to the enabled queue 
° the message is discarded if the queue has been disabled. 
- if the terminal is connected to a VCAM subsystem, then one of the alterna- 
tives occurs, 
° the message is sent directly to the VCAM subsystem 
° the message is discarded if the terminal in question is to receive data, 
that is, an output message. 


2-09 


Output Requests 


When an output request is outstanding, the BTNS output request routine moves the 
message into the BTNS buffer pool associated with the line to which the destina 
tion terminal is attached, and the output request is queued until it can be 
honored. 


Notification of the BINS output request routine means that, 
- for an MCS COBOL program, the message has been sent to the output queue as- 
sociated with the destination terminal 
- for a VCAM subsystem, the subsystem itself identifies the message and the 
terminal to which it is to be sent. 


An output request is honored when an end-of-operation occurs on a line , iee@, 
- when a data exchange (input or output) has been completed 
« when an end to the polling cycle is requested by BTNS. 


Output requests are queued as they are received and are handled on a first-in/ 
first-out basis according to the following scheme, 
e Output requests for VCAM subsystems are serviced before those for MCS COBOL 
programs 
« when no further output requests for VCAM subsystems are pending, the BINS 
output request routine will then service output requests for MCS COBOL pro- 
grams; if an output request for a VCAM subsystem should occur at the time 
when output requests for MCS COBOL programs are being serviced, servicing of 
the MCS COBOL requests is halted to allow the VCAM request to be serviced. 


If there are no output requests pending for the line, polling of the line conti- 
nues according to the scanning sequence declared at network generation, ieee, 
"round-robin" or "linear". 


MESSAGE PROCESSING 


The general format of a message exchanged over a line can be represented as fol- 
lows, 


header message-text trailer 


The actual format a message takes is dependent on the line procedure used, viz., 


TTY line procedure 


- VIP line procedure 

e BSC line procedure 
The line procedures and terminal programming considerations are treated in 
Appendix B. MCS data formats are treated in Section IV. 


The focus of the message processing routines is the logical header of the mes- 
sage, namely, 
e for an input message, the logical header is built by IURP firmware from the 
transmission header sent by the terminal 
« for an output message, the message processing routines pass a logical header 
to the TuRP firmware which converts it into a transmission headers 


ERROR HANDLING 


The 


communications link comprises a variety of equipment including, 


terminals 
modems 
lines 
adapters 
ProceSSOrSe 


A hardware error in any of these components must be recognized by the system and 
handled as follows, 
e recovering from the error condition 
« logging the incidence of errors for statistical purposes and maintenancee 


Error Recovery 


Recovering from hardware errors is done by both BTNS and IURP firmware (MLA). 


unrecoverable errors 


recoverable errors 


These errors are normally hardware failures detected 
by the MLA during line initialization or message ex- 
changee An error thus detected is reported to the BINS 
error handling routine which performs the following, 

- closes the line or terminal affected 

- notifies the network control operator. 

When either the line or terminal has been repaired, it 
can then resume transmission when an RT network con- 
trol command identifying the entity is issued. 


If the error is detected during line initialization, 
the system console operator has the option to request 
a retry or exclude the line from being used by the 
communications Sessions 


A transmission error results in abnormal termination 
which can be caused by, 

- a parity error over the line 

- a loss of characters due to line interference. 

When this type of error is detected by the MLA, it 
attempts a number of retries specified at network gen- 
erations If none of the retries is successful, the er- 
ror is considered unrecoverable and handled as abovee 


Error conditions which can be recovered thru operator 
intervention include the following examples for the | 
overflow condition on the VIP7700 which results in the 
ERROR indicator being illuminated on the terminal, 
- where the operator has failed to clear the screen, 
the actions for recovery are, 
° clear the screen 
° issue the RDY communications command 
- where the message size is too great for the screen, 
the actions for recovery are one of either, 
© issue the MTE communications command altering the 
"line-length" and "block-size" to truncate the 
message to a defined size 
° issue the RDY STRONG network control command to 
cancel the message. 
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Error Logging 


All hardware errors known to BINS are classified as either retryable or nonretry- 
able and are logged accordinglye 


Error logging is described in the System Operation: Operator Guide Manual, 
SHUTDOWN FUNCTIONS 


The communications session is shut down when BINS is terminated, 


Normal Shutdown 


BINS is terminated normally when the TT network control command is issued which 
results in the following, 
e each line is systematically closed after all MAM exchanges on the line are 
completed 
« VCAM subsystems are notified in order to be able to terminate exchanges at 
a "clean point" and disconnect any terminals 
« housekeeping duties are then performede 


Fast Shutdown 


Issuing the TT STRONG network control command results in a fast shutdown, namely, 
e all lines are closed 
» VCAM subsystems are notified that a fast shutdown is in progress 
« the network control or system console operator is notified 
« housekeeping duties are then performed, 


Emergency Shutdown 


Such a condition is due to an internal failure of BINS affecting its performances 
The procedure for emergency shutdown is the same as that for fast shutdown 


Housekeeping Duties 


Housekeeping duties performed at shutdown include, 
e deleting BINS buffer pools 
e disabling attention notifications on all lines 
e clearing the areas used to enqueue output requests for VCAM subsystems, if 
present 
e terminating the communications job stepe 


MESSAGE SWITCHING THRU BTNS 


BTNS provides two methods of message exchange between terminals, thereby bypass- 
ing both MCS COBOL programs and VCAM subsystems, which are 

« direct exchange 

e queued exchange ° 


Direct Exchange 


Messages can be exchanged directly between terminals by issuing the BT communi- 
cations command at the sender terminal specifying the receiver terminal and the 
message texte The receiver terminal is informed of the identity of the sender 
terminal by the network control interface which precedes the message text with 
FROM followed by the name of the sender terminal. 


The conditions under which the command can be used are, 
e both sender and receiver terminals are active and known to the site control- 
ler 
« the receiver terminal is other than a cassette. or processor 
e the message text does not exceed 128 characterSe 


Queued Exchange 


The sender terminal uses the log-on procedure to identify the eventual destina- 
tion of the message, which can be either another terminal or itself, 


During log-on, one of the following messages appears, 

« CCOO ID,APPL? 

e CCO1 ID,USER/PROJECT/BILLING, APPL? 
In response to APPL, the operator can key in the name of the receiver terminal 
or enter a "space'' as an option if the receiver terminal is itself. 


The only prerequisite is that the terminal and, by implication, its related 
queue which bears the same name, are defined at network generatione 


e echo exchange : 


This involves sending back the message to the sender terminal thereby 
verifying its ability to send and receives 

When the terminal transmits a message, BINS places it in the queue named 
at log-on, ieee, the name of the terminal itself. When BINS scans for 
output requests to the line, it discovers the message in the queue and 
sends it back to the sender terminal. 


e exchange between interactive terminals : 


Such an exchange is possible with terminals having both input and output 
capabilitye 

Two terminals, say, can log on to each other's queue whereby messages 
input on the one terminal are output on the other terminal, and vice ver- 
Sa, ieee, assuming that both the terminals are connected. 

If one of the terminals is not connected at the time that the other is 
transmitting, the messages input are stored to the capacity of the queue 
until such time that the receiver terminal logs one The stored messages 
are then delivered to the receiver terminal. 


e sending messages to a cassette? 


The sender terminal is logged on to the queue related to the cassette 
» which will eventually be the receiver terminal. The cassette 
is logged on to the same queue in order to receive messages in- 
put to it by the sender terminal. 
More than one sender terminal may log on to this queuee 
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Queued Exchange 


Echo Exchange 


- terminal Tl transmits a message which BINS places in queue Tl 
e when BINS scans for output requests on line L1, it finds the message in 
queue T1 and sends it back to terminal T1 


Exchange between Interactive Terminals 


terminal Ti transmits a message which BTNS places in queue T2 

when BINS scans for output requests on line L2, it finds the message in 
queue T2 and sends it to terminal T2 

terminal T2 transmits a message which BINS places in queue Tl 

when BTNS scans for output requests on line Li, it finds the message in 
queue T1 and sends it to terminal T1 


Sending Messages to a Cassette 


« terminals Ti and T2 transmit messages which BINS places in queue CAS 
. the messages are delivered to the cassette associated with 
the queue CAS 


SECTION III 


MESSAGE ACCESS METHOD 


MAM (Message Access Method) provides the means for the exchange of messages. It 
operates with BTNS (Basic Terminal Network Support) to form the Message Control 
System (MCS). MCS is the interface between the communications program and the 
terminals. 


MAM is described in terms of: 
« Communications elements of MCS COBOL 
« Queue correspondence 
- Structure of an MCS COBOL load module 
- Device handling and message editing 
- Dialog handling 
- Data integrity 
- Communication between local MCS COBOL programs 
« Communication between remote applications 


COMMUNICATIONS ELEMENTS OF MCS COBOL 


The MCS COBOL communications elements are: 
« The communications description (CD) area of the MCS COBOL program 
- The communications verbs 
- Message delimiters 


CD Area of the MCS COBOL Program 

CD areas contain information about queues, terminals and messages to be input 
and output. The MCS COBOL program must have at least 1 CD area for messages to 
be sent or received. If the application requires messages to be sent and 
received, then at least 2 CD areas, the input CD area and the output CD area, 
must be present. 


Communications Verbs 


The 5 communications verbs are: 
» ACCEPT 
« DISABLE 
« ENABLE 
e RECEIVE 
e SEND 


The communications verbs provide the user interface as follows, 


» between MCS and the application, 

- ACCEPT : the MCS COBOL program ascertains the number of messages in a 
symbolic queue thru the ACCEPT with COUNT (ACCEPT MESSAGE 
COUNT) statement. 
Coding in the statement includes the name of the input CD area 
identifying the symbolic queue whose message number is to be 
ascertained. 

- RECEIVE : requests a message from a specified symbolic queue identified 
in the input CD area. 

- SEND : directs a message to a specified symbolic queue identified in 
the output CD area. 


» between MCS and the terminals, 
- DISABLE : terminates the logical connection with specified sources or 
' destinations for data transfer. 
- ENABLE : establishes the logical connection with specified sources or 
destinations for data transfer. 


The status of the MCS COBOL interface is given by a set of key codes which are 
described in Appendix H. 


Message Delimiters 


A message is delimited by either an EMI (end-of-message indicator) or an EGI 
(end-of-group indicator). 


The END-KEY value of the message delimiters are, 
e "2" for EMI 
- "3" for EGI 


The following cases denote the way in which messages are delimited: 


« from the terminal to the application (input), 

- non BSC terminal : the message is delimited by an END-KEY value of "3" or 
EGI. 

- BSC terminal : each block is terminated by the control character "ETB" 
(End-of-Transmission Block) and is treated by the 
application as an END-KEY value of ''2'' or EMI. 

The final block terminating the message text is 
delimited by the control character "ETX" (End-of-TeXt) 
and is treated by the application as an END-KEY value 
of ''3" or EGI. 
NOTE : Where the message is of "zero" length, the 
END-KEY value may be either "2" or "3", 
After coding a RECEIVE verb, the programmer 
should test for the STATUS KEY code, TEXT-LENGTH 
and END-KEY before deciding if there is a 
message to be processed. 


» from the application to the terminal (output), 
- non BSC terminal : the message can be delimited by an END-KEY value of 
either "2" (EMI) or "3" (EGI). 
In the case of TWA (Two-Way Alternate) mode, see QUEUE 
command in Section V, the EGI is necessary to allow 
dialog. 
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- BSC terminal : the message is transmitted in blocks, the maximum size 
of which is dependent on the type of the receiving 
terminal. 

A SEND with EMI statement results in the transmission 
of a data block terminated by the control character 
NETB, 

A SEND with EGI statement results in the transmission 
of a data block terminated by the control character 
METX, 


+ communication between applications, 
EMI and EGI delimiters are transmitted by MCS and converted into the 
appropriate END-KEY value in the destination CD when a RECEIVE statement 
is issued. 


QUEUE CORRESPONDENCE 


A queue is a container in which messages are stored and from which messages can 
then be retrieved for later processing on a first-in-first-out basis. Depending 
on application requirements, the queue can be specified either in main memory or 
on a disk file. 


Queue correspondence involves: 
- The definition of the physical queue 
- The definition of the symbolic queue 
» Relating the physical queue to the symbolic queue 


Physical Queues 


Physical queues are defined at network generation by the QUEUE command, see 
Section V, and are identified by external-queue-names. 


The physical queue can be 

» a terminal queue : an output queue thru which a message is sent to the 
terminal. 
The name of the terminal queue is the name of the 
terminal as identified in the TERMNL command. 

* a program queue : an input queue thru which a message is sent to the MCS 
COBOL program 
The name of the program queue is the name of the 
application specified during the log-on of the terminal. 


Symbolic Queues 


Symbolic queues are logical queues defined in data-name-1 of the CD area in the 
MCS COBOL program. The queue can be either input (message reception) or output 

(message dispatch). In the case of the symbolic input queue, further partition- 
ing into subqueues is possible by defining these in data-name-2 of the CD area. 
Only one level of subqueues is permitted. 


Relating Physical Queues to Symbolic Queues 


The $QASSIGN statement, see "Executing a Communications Step" at the end of the 
section, defines the symbolic queue or subqueue and establishes its correspon- 
dence with the physical queue. This correspondence is unique. 
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The $QASSIGN also defines the processing mode as follows, 


symbolic input queues 


symbolic output queues ; 


symbolic I/O queues 


a symbolic input queue must be defined for each 

program queue from which messages are to be 

received by the program 

The IN keyword cf the $QASSIGN serves . 

- to identify the symbolic queue as an input queue 

- to allocate the program queue to the current step 
until step termination. 

No other MCS COBOL program may issue a RECEIVE 

Statement to the program queue thus allocated. 


each terminal to receive output has an associated 
terminal queue for which a symbolic output queue is 
defined. 


Explicit definition of the symbolic output queue : 


The OUT keyword of the $QASSIGN serves 

- to explicitly identify the symbolic queue as an 
output queue 

- to allocate the terminal queue to the current 
step until step termination. 

The terminal is known to the MCS COBOL program 

exclusively by its explicitly defined symbolic out- 

put queue. When a message is received from this 

terminal, the symbolic source field of the input CD 

is updated by MCS with the output queue name. 

No other MCS COBOL program may issue a SEND command 

to this terminal queue and the terminal cannot be 

connected to another MCS COBOL applications 


Implicit definition of the symbolic output queue : 


The symbolic output queue is defined implicitly 
thru the log-on procedure of the destination 
terminal. When a message is received from the 
terminal, the symbolic source field of the input CD 
is updated by MCS with the name of the associated 
terminal queue. The symbolic source name will be 
used as the symbolic output queue to which messages 
are Sent. 

This method cannot be used if no meSsage is sent 
from the terminal to the application 


a symbolic input/output queue is a program queue 

and hence does not have subqueues. 

The INOUT keyword of $QASSIGN serves 

- to identify the symbolic queue as an input/output 
queue 

- to allocate the program queue to the current step 
until step termination. 

No other MCS COBOL program may issue a SEND or 

RECEIVE command to the program queue thus allocated. 


Queue Correspondence 


Terminal Program Symbolic Symbolic 
Queues Queues Subqueues Queues 


COB1 


ORDERS 
aa INQUIRIES 
RESERVATIONS 


PRTDALL 


STOCK 


“= PRTHDO: | esse ces seca tee es dees eetecee ese 


Program COB1 queue relationship 


- Each of the program queues is related to a corresponding symbolic subqueue 
as follows, ORDERS to ORD, INQUIRIES to INQ and RESERVATIONS to RSV. 

« The symbolic subqueues ORD, INQ and RSV are associated with the symbolic 
queue INPUT which means that when a RECEIVE statement is issued to INPUT, 
its subqueues are scanned until a message is found in 1 of them, eege, INQ 
if say either T1 or T2 is logged on to INQUIRIES. 

« The symbolic output queues PR1 and PR2 are related to their respective ter- 
minal queues PRTDALL and PRINY associated with receive-only printers. 


Program COB2 queue relationship 


« The direct correspondence of the program queue STOCK to the symbolic queue 
INPUT means that input is received from any terminal logged cn te STOCK. 

« The symbolic output queue PR is related to the terminal queue PRTHDQ asso-~ 
ciated with a receive-only printer. 
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STRUCTURE OF AN MCS COBOL LOAD MODULE 


An MCS COBOL load module comprises 1 thru 6 user processes which are basically 
equivalent to tasks and linked together by the Static Linker, see Section VI. 
Each process is associated with a program or "run-unit". 


System handling of the load module is as follows, 


» monoprocess load module : the system executes a call to the entry point of 
the monoprocess load module specified by the 
uSere 
On termination of the process, a call is made to 
“MAM to perform housekeeping functions, whether 
the process terminates normally or abnormally. 
As a result of this feature, the program must be 
terminated with an EXIT PROGRAM statement and not 
a STOP RUN statement which returns control 
immediately to the system 


- multiprocess load module : the system procedure STUSERS starts each of the 

STUSERn processes, n ranging from 1 thru 6. 

Each STUSERn executes a call to the program thru 

a uSer-specified entry pointe 

On termination of the process, STUSERn calls MAM 

to perform housekeeping functions before return- 

ing control to STUSERS. 

When all processes have terminated and all house- 

keeping functions have been performed, STUSERS 

terminates automatically. 

The constraints for the multiprocess load module 

are : 

- the programmer must synchronize accesses to 
shared files, see "Communication between 
Processes of a Multiprocess Program" later in 
the section | 

- the checkpoint/restart facility is not avail- 
able 

- only one process can execute the ACCEPT and 
DISPLAY verbs to gain access to the standard 
SYSIN and SYSOUT files. 
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DEVICE HANDLING AND MESSAGE EDITING 


An MCS COBOL program is capable of such control functions as, 
- sending control messages 
- being notified of status changes 
« controlling data flow 


Control Messages 


Control messages are commands affecting the MCS COBOL program-to-terminal 
interface and can be passed between the program and BINS. The program views the 
command like any other message that it sends to a terminal. 


The format of the command is : 
><CTLxxx, where xxx is a 3-character mnemonic variable for the command. 


The types of commands are, 

- BRK : interrupt request 

e CNT : connection of a terminal 

- DIS : disconnection of a terminal 

« PRG : program request to BINS to purge all existing messages in a terminal 
queue; the command is given top priority in the queue by BINS 

- RVI : program to issue a "reverse interrupt'' to a BSC (Binary Synchronous 
Communications) line procedure terminal related to the specified out- 
put queue; the command is stored in the queue and processed in 
sequence 

- SHT : request to application to shutdown 


Points to note: 

- The BRK, CNT and DIS commands should only be used for terminal simulation 
purposes. The application receiving these commands will be notified by the 
corresponding STATUS KEY code in the input CD. 

e The SHT command can also be sent by the BT network control command of the 
format : BT xxxx ><CTLSHT, where xxxx is the program-queue-name, see 


Communications Network Control Terminal Operations Manual. 


When a control message arrives in the destination queue, the count of available 
messages in the queue is incremented by 1. The message type is detected by the 
"receiver'! and reflected by a specific value of the status key. On completion 
of the RECEIVE statement, both parameters TEXT-LENGTH and END-KEY will be 0. 


Status Changes 


If the program queue has been defined with the BREAK option at CNC 
(Communications Network Configurator) generation, status changes of the 
terminal or of the system will be passed to the application thru the status key 
of the input CD as a result of a RECEIVE statement. The symbolic source 
identifies the related terminal. 


If the BREAK option has not been specified, then the user will not be nctified 
of any events occurring when a RECEIVE statement is issuede 


Status key codes are explained in detail in Appendix H 
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Data Flow Control 


The control of data flow between MCS and the terminals is thru the ENABLE and 
DISABLE verbs functioning as follows, 


Input without terminal : 


Input with terminal 


Out put 


ENABLE INPUT 

The related program queue specified in the input 

CD is "enabled", iee., connection requests from 

terminals can now be accepted. 

NOTE : Terminals described in CNC with automatic 
log-on and assigned to one of queues or 
subqueues will be immediately connected. 


DISABLE INPUT 

The related program queue specified in the input 
CD is "disabled", iee., no more connections to the 
queue can be accepted and any terminals previously 
connected are now disconnected. 

The application may continue to empty the queue 
thru RECEIVE statements and when the queue is 
empty, the status key is flagged as "disabled". 


ENABLE INPUT TERMINAL 

The terminal whose name is specified as the 
symbolic source in the input CD can commence or 
resume input to the queue to which it was 
connected. 


DISABLE INPUT TERMINAL 

The terminal whose name is specified as the 
symbolic source in the input CD can no longer 
transmit in input mode. 


ENABLE OUTPUT and DISABLE OUTPUT apply only to 
terminal queues. 

If either verb is applied to program queues, no 
action results or a status key of "'9F"' is flagged. 


ENABLE OUTPUT 

The related terminal queue specified in the output 

CD is "enabled" as follows, 

- if the terminal is working in input mode, output 
to the terminal is resumed 

- if the terminal is working only in output mode, 
then the terminal becomes activated. 


DISABLE OUTPUT 

The related terminal queue specified in the output 

CD is "disabled" as follows, 

- if the terminal is working in input mode, output 
to the terminal is suspended 

- if the terminal is working only in output mode, 
then the terminal becomes deactivated 

- the application may continue to send messages to 
the queue. 
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ENABLE and DISABLE 


ENABLE INPUT 


< 


ENABLE INPUT with input CD specifying 
QA : connection requests to the queue 
and its subqueues are now accepted. 


ENABLE INPUT TERMINAL 


ENABLE INPUT TERMINAL with input CD 
specifying Tn, where Tn identifies the 
terminal and its related queue : 

the terminal identified can now trans- 
mit in input mode. If T2 is specified, 
it can transmit; other terminals con- 
tinue to remain in the state they ori- 
ginally were. 


ENABLE OUTPUT 


ENABLE OUTPUT with output CD specify- 
ing Tn, where Tn identifies the 
terminal and its related queue : 

data flow can now resume from the 
queue to its related terminal. 

If Tl is specified, then only the 
queue T1 and its related terminal are 
"enabled". 


4 


DISABLE INPUT 


fC / 
M 
S 
Tn <q 


DISABLE INPUT with input CD specifying 
QA : all connected terminals are now 
disconnected; the application may 
continue to empty the queue. 


T1 
T2 


DISABLE INPUT TERMINAL 


T1 At 
saueee 
m < : 


DISABLE INPUT TERMINAL with input CD 
specifying Tn, where Tn identifies the 
terminal and its related queue : 

the terminal identified can no longer 
transmit in input modee If T2 is spec- 
ified, it ceases to transmit; other 
terminals continue to remain in the 
State they originally were. 


DISABLE OUTPUT. 


1 < 
uel 


Tn <q Tn queue 


DISABLE OUTPUT with output CD specify- 
ing Tn, where Tn identifies the 
terminal and its related queue : 

data flow is halted from the queue to 
its related terminal. 

If T2 is specified, then only the 
queue T2 and its related terminal are 
"disabled". 


T1 queue 
T2 queue 


DIALOG HANDLING 


Dialog between the application and the terminal is handled according to the type 
of application, namely, 

» Non-interactive applications 

» Interactive applications 


Non-interactive Applications 


A typical non-interactive application involves the following stages, 


- Data Entry : The application may be absent at the time when data is 
collected fromterminals into program queues. Only BTNS has 
to be present in the system and the terminals must be 
connected to program queues. 

In order to allow the terminal to enter data without the 
application being present, the program queue must be 
described at CNC generation without the TWA option, ieee, 
defining the queue as a data entry queue. 


- Batch Processing : When all data has been entered, the application can begin 
processing during off-peak hours, say, later at night. 
Processing involves updating files and preparing output 
data to be placed into terminal queues. 
BTNS is absent during batch processing. 


« Data Distribution : BTNS empties the output data in the terminal queues to 
the respective terminals when these are activated. 
The application may be absent during data distribution 


The dialog between the terminals and their related queues, and between the 
application and the data entry queues is not restricted, ieee, data flow is 
permitted in either direction. 
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Non-interactive Application 


data entry 


data entry queue 


terminal queue 


1 Terminals T1 and T2 can enter data at will to the data entry queue which 
is a program queue declared without the TWA option. 


batch process ing 


data entry queue 


terminal 


2 Data collected previously from the terminals can now be processed at a 
time when the terminals have ceased transmission. 


data distribution 


[data entry queue] 


terminal queue 


3. When the terminals are activated, BINS outputs the results at a time when 
the application program may be absent. 
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Interactive Applications 


Typical interactive applications are either transactional or inquiry-response 
applications. 


The TWA option determines the way in which the dialog is handled by the system 


» With TWA option : The program queue must be described with the TWA 
option at CNC generation. This enables an application- 
terminal dialog on a message basis. 


On connection, the terminal has the turn-to-transmit. 
A message transmitted by the terminal is delimited by 
a COBOL END-KEY value of ''3" (EGI) and the application 
then has the turn-to-transmit. 

The application can then transmit using the SEND 

statement. 

Transmission by the application is performed as 

follows, 

- Several messages delimited by EMI (end-of-message 
indicator) can be transmitted and the turn-to-trans- 
mit is still retained by the application 

- A message delimited by EGI (end-of-group indicator) 
transfers the turn-to-transmit to the terminal. 


The terminal's turn-to-transmit can be overridden at 
any time by the application 


» Without TWA option : In this case, the terminal can transmit messages at 
will. 


For the visibility of messages by the application, 
see "Message Delimiters"’ earlier on in the section. 
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Interactive Application with TWA Option 


a 
ay 
NOG 


application 


1 Terminal T1 enters a message into the program queue QUERY which has been 
declared with the TWA option at CNC generation 
The message is delimited by an END-KEY value of "'3'' to denote EGI. 


2 The message is RECEIVEd by the COBOL application for processing. 


COBOL 
application 


3 After the application has processed the message, it can SEND several 
messages delimited by EMIs to the terminal queue Tl. 2 eee 
For as long as messages from the application are delimited by EMIs, the 
turn-to-transmit is still retained by the application and any message 
entered on the terminal will be discarded. 


4 As soon as a mesSage is available for output, MCS will begin transmission 
to the terminal. 


(Query _| 


COBOL 
application 


5 The last message in the stream to be sent by the application is delimited 
by EGI. 
Altho EGI transfers the turn-to-transmit to the terminal, the application 
can override the terminal. 


6 When the terminal receives the last message, it can then enter another 
message to the application 
If overridden by the application the terminal can transmit later. 


3-13 


DATA INTEGRITY 


The safeguara features in MAM to protect against loss of data are, 
- retention of messages in terminal queues 
» retention of messages in program queues 
- checkpoint/restart facility 
- control cf message and queue overflow 


Retention of Messages in Terminal Queues 


When an MCS COBOL program issues a SEND statement, a status key assigned to the 
ctivity is set to a value which can be tested by the user as follows, 
- if the status key denotes an incident, the message is net released 
» if the status key denotes 'normal'' conditions, then the message is released 
to the terminal queue under the charge of the system 


When the receiving terminal is ENABLEd and BINS is active, MCS attempts to 
transmit the message from the terminal queue to the associated terminal as 
follows, 
- if transmission is successful, the message is deleted from the terminal 
queue 
- if transmission is not successful, several retries according to the number 
specified are attempted 
- if transmission is persistently unsuccessful, the terminal queue is 
"closed" but the message is retained in the queue. 


The message is retained in the queue until one of the following occurs, 

- it is ultimately and successfully transmitted to the terminal 

» a Shutdown is effected; if the terminal queue is a core queue or disk queue 
without the RESTART option, then the message is lost 

- H_CNC step is executed; even if the terminal queue is specified with the 
RESTART option, the message is lost 

- ISL with REFORMAT option is performed; even if the terminal queue is 
specified with the RESTART option, the message is loste 


Message retention in terminal queues applies under such conditions as, 
» BINS "abort" 
» System crash 


Retention of Messages in Program Queues 


A message which is successfully placed in a program queue is retained until one 

of the following occurs, 

- it is successfully retrieved by the application for processing 

- a shutdown is effected; if the program queue is a core queue or disk queue 
without the RESTART option, then the message is lost 

- H_CNC step is executed; even if the program queue is specified with the 
RESTART option, the message is lost 

» ISL with REFORMAT option is performed; even if the program queue is 
specified with the RESTART option, the message is lost. 
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Checkpoint/Restart Facility 


The 


The 


facility allows the following functionalities, 

disk queues to be journalized in order to be rolled back, see RESTART option 
of the NDL QUEUE command in Section V 

the uSer program to be restarted if the REPEAT option has been specified in 


conditions for which the facility is used are, 
Step abort 
system crash. 


purpose of the facility is to ensure that the queues, the application pro- 


gram and user files are in the same state when restart takes place , as they 
were at the last checkpoint. If checkpoints have not been taken, then restart is 
at the beginning of the step. 


The 


features of the facility are, 


issuing checkpoints : 


Only MCS COBOL monoprocess programs with disk queues can issue checspeines 

by; 

- RERUN statements thru which checkpoints are taken at specified intervals 
of records processed for a particular file, see COBOL Language Reference 
Manual 

- CALL statements issued to a system checkpoint procedure at appropriate 
places in the program, see COBOL User Guide. 


The program queue is journalized if it has been 

- defined on disk with with the RESTART option in the ePEToPE take QUEUE 
command at CNC generation 

- identified as an input queue for the step by the $QASSIGN statement spe- 
cifying either the IN or INOUT parameters. 


Journalization is performed on the disk queue file itself and no addition- 
al file space need be allocated. 

A journal is considered "active" for a given program queue only for the 
duration of the MCS COBOL program step. 


Checkpoints have no effect on terminal queues except for terminal queues 
corresponding to a L64 GPU, to be discussed later in "Communications be- 
tween Remote Applications". 


implementing checkpoints : 


For program queues described with the RESTART option, disk space related 
to messages received will be released only at checkpoint time or on termi- 
nation of the MCS COBOL program. The user must take this into account 

when defining the size of those program queues at CNC generation and when 
deciding the frequency of checkpoints in his program 


When reading messages from a program queue, the "head-of-queue'' marker 
points to the next message to be RECEIVEd by the application. 

The "checkpoint'' marker points to the positien of the "head-of-queue" mar- 
ker at the time of the last checkpoint. 

In the case of "restart" of the program, the "head-of-queue'' marker is 
then restored to the "checkpoint" value. 


Implementing Checkpoints 


queue Status after checkpoints 


“head-of-queue!! 
marker 


"checkpoint" 
marker 


At time tO, both "head-of-queue" marker and "checkpoint" marker point to 
the message indexed Ml. 


RECEIVE 


COBOL 
application 
"checkpoint" 
marker “"head-of-queue"! 
marker 


time ti, the following has occurred, 

the COBOL application has RECEIVEd the messages indexed M1 and M2 

the "head-of-queue" marker now points to the message indexed M3 

the "checkpoint'' marker has not moved and still points to the message Mi. 


RECEIVE 


application 
"checkpoint"! 
marker “"head-of-queue"' 
marker 


At time t2, when the application has successfully processed the messages 
indexed M1 and M2, and taken a checkpoint, the following has occurred, 
the "checkpoint" marker has moved to point at the message indexed M3 
messages M5 and M6 now arrive in the queue 
the application has now RECEIVEd messages M3 and M4 
the "head-of-queuve" marker now points to the message indexed M5. 


an abort now occurs, the status at RESTART will be, 

the "head-of-queue!' marker will be "rolled back" to the position of the 
"checkpoint'"' marker, namely to the message indexed M3 

the messages to be RECEIVEd by the application will be M3 ,M4, M5 and M6. 


conditions for restart : 
A job step can be restarted at the beginning or from the latest checkpoint 
if the $STEP statement contains the REPEAT parameter. 


- Restart after step abort: 


Queues assigned to the step with the RESTART option, are rolled back 
to the previous checkpoint if the step is restarted. Otherwise, they 
are left in the state they were at the time of the abort, in which 
case, they can be printed out by the use of the QMAINT utility for 
debugging purposes 


A114 ode be ee mee A a 
AiL Otner queues are 


- Restart after system crash: 
Queues assigned to the step are treated as follows, 


Terminal and program queues Specified without the RESTART option are 
reinitialized. 

Terminal queues defined with the RESTART option are restarted from the 
next message following the last message successfully transmitted. 

If the crash occurred during transmission, the queue is restarted with 
the message being transmitted. 

Restart of terminal queues with the CTLRST option, see Section V, is 
dealt with in "Communications between Remote Applications". 

Program queues with an active journal are "rolled back" to the last 
checkpoint taken or to the beginning of the step. 

Program queues with the RESTART option but without an active journal, 
ie @e, queues not assigned by the MCS COBOL program at the time of the 
crash, are restarted from their current state. 


Points to consider; 


The MCS COBOL program restarted from a checkpoint will process the 
first message in the symbolic queue. This message may have been 
already processed and caused the delivery of an output message, in 


which case, the output message is duplicated. 


If the program wishes a terminal to be aware of its checkpoints, it 
can send a meSsage to the terminal indicating the checkpoint number. 
On restart from checkpoint "i", the program should send a message to 
the terminal indicating restart from checkpoint "i", so that the 
terminal operator is aware of the repetition of messages. 


Messages being transmitted at the time of crash should be retrans- 
mitted by the terminal operator at restart; the program should check 


for redundant messages by requiring that all input messages include 
sequence numbers. 

If the program queue needs to be purged following a restart, the pro- 
gram may purge the queues by issuing a series of RECEIVE statements 
equal to the message counte 


- MAM initialization 
The choice of action for the system console operator when starting up 
MAM in the case where disk queues existed for the previous session are, 


MAM=YES All queues without the RESTART option are purged. 


Terminal queues with RESTART commence following the message 
successfully transmitted or at the one being transmitted. 
Program queues with RESTART commence from 
° the "head-of-queue'" for normal termination of the session 
° the last checkpoint under the conditions, 

- that the queues have an active journal 

- that the session terminated abnormally. 
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e MAM=NO 


Unless a new CNC session takes place, MAM is not available. 
Disk queue contents remain in the state they were at the 
time of termination of the session. 

This action is taken in cases where MAM is not required to 
Save Start-up time and space in system resident memory. 


« MAM=REFORMAT MAM start-up operations are performed whereby all queues 


are reinitialized. 
The disk queue file is reformatted using the copy of the 
telecommunications system tables in backing store. 


Points to consider in using the RESTART facility, 
- Program queues can be filled during a session when no MCS COBOL programs 


are active 


- The contents of such queues can then be retrieved in subsequent sessions 
when MCS COBOL programs are executed. 


Control of Message and Queue Overflow 


When the message size limit or queue capacity is exceeded, an overflow condition 
results which causes the STATUS KEY clause of the CD area to be updated with the 
appropriate return code to inform the user. For details of Status Keys, see 


Appendix H and the COBOL Language Reference Manual. 


« message overflow : 


queue overflow 


The maximum message length is related to the queue block 
size parameter declared at CNC generation. 

See Section V "QUEUE command" (QDBLKSZ for disk queues, 
QCBLKSZ for core queues). 


Maximum message length is given by the algorithm, 
[ cb - 50) 24 + 2x[(b- 4) +4]]x (b - 5) 


where b = queue block size, and 
+ = integer division 


When message length, including control characters or marks, 
is exceeded, the excess portion of the message is 
truncated. 

Status key cede setting is as follows, 

- 94, (MSGOV) for the sender 

- 95, (NOTALL) for the receiver. 


Maximum message size shculd be defined by the application 
according to, 

- terminal display size 

- transmission line errors. 


When there is insufficient space in a queue io contain a 
message sent to it or to handle I/O transfers, the message 
is discarded and the status key is set to the appropriate 
value. 

When a queue overflow condition occurs on a SEND statement, 
the application should issue a CALL to the timer before 
attempting to execute that SEND. 


Status key code setting for the relevant condition is, 

- 91, (SPACENAV) for the sender to be notified of lack of 
space in a disk queue 

- 92, (BUFNAV) for the sender and the receiver to be 
notified that there is insufficient memory space to 
handle a disk 1/0 operation during message transfer 

- 95, (NOTALL) for the sender to be notified that the 
number of core blocks is insufficient. 


COMMUNICATION BETWEEN LOCAL PROGRAMS 


The term "local" implies that the programs are in the same central processore 
Communication is established by manipulating program queues. The program queue 
whose name is to appear in the symbolic source of the destination input CD is 
specified by the keyword REPLY in $QASSIGN OUT. 

The ENABLE and DISABLE verbs are ineffective. 


The 3 types of local communication are, 
« Program-to-program communication 
» Program communicating with itself 
« Communication between processes of a multiprocess program 


Program-to-program Communication 


Program-to-program Communication 


symbolic program symbolic 
queues queues queues 


RECEIVE 


Program A Program B 


Program A receives as input, messages supplied by program B and vice verSae 
The queue assignments required to allow these exchanges are as follows, 


- Program A : The symbolic queue INPUT must correspond to program queue QA 
for input (parameter IN). 
The symbolic queue OUTPUT must correspond to program queue QB 
for output (parameter OUT) and must be specified with REPLY=QA. 


- Program B : The symbolic queue INPUT must correspond to program queue QB 
for input (parameter IN). 
The symbolic queue OUTPUT must correspond to program queue QA 
for output (parameter OUT) and must be specified with REPLY=QB. 
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Program Communicating with Itself 


Program Communicating with Itself 


program 


program symbolic 


The program communicates with itself in the following stages, 
» It acts as a terminal and fills the program queue QA 
- It then receives messages from the same program queue QA as it would 
receive messages from any terminal connected to ite 


The queue assignment required for this exchange is : 
» The symbolic queue INPUT corresponds to program queue QA for input and out- 
put (parameter INOUT) and must be specified with REPLY= QA. 


Communication between Processes of a Multiprocess Program 


Communication between Processes of a Multiprocess Program 
Sharing a File between Processes 
multiprocess 
program 


program symbolic 
queue queue 


ou PROCESS 
B 


ACCESS ‘ 
PROCESS 
A 


1 Process A issues RECEIVE to program queue ACCESS thru symbolic queue FILE, 
2 When acknowledged, Process A can access the "shared file". 
3 Process A SENDs message to ACCESS to notify Process B "shared file" is free. 
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The queue assignment required to regulate exchanges between processes for access 
to a shared file is : 
« The symbolic queue FILE corresponds to program queue ACCESS for input and 
output (parameter INOUT). 


The programmer is responsible for synchronizing file accesses to a shared file 
for multiprocess MCS COBOL applicationse The same mechanism can be used on a 
queue as "'access" between several applications belonging to different steps 


~~ ae 


generation 


The stages in implementing file sharing are, 

- At step execution, the program must prime the program queue ACCESS with a 
message which serves to notify the first process wishing to access the 
"shared file'' that it is available. 

Process A issues a RECEIVE statement to the program queue ACCESS thru the 
symbolic queue FILE and when the message is received, Process A has access 
to the "shared file". 

When Process A has finished with the "shared file", it SENDs a message to 
ACCESS which serves to notify Process B that the "shared file" is now 
available to be accessed. 


COMMUNICATIONS BETWEEN REMOTE APPLICATIONS 


The term "remote"! implies that the programs are in different central processors 
which are linked thru a BSC (binary synchronous communication) line procedure. 
Communication is established at any given time by only 2 applications at either 
site by means of describing the other site as a BSC terminal with the following 
parameters (see TERMNL command in Section V), 

« STYPE=CPU 

e AUTO 

« ASSIGN=program- queue 


Communications between remote applications is described in terms of, 


« Implementation 
« Recovery on the Emission Side 


- Recovery on the Reception Side 


Implement ation 


The communications link-up is established at both sites by, 
« The CNC description for the network 
« The run-time JCL 
» The sender and receiver applications. 
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Communication between Remote Applications 


Site 1 Site 2 


Program A Program B 


symbolic physical physical symbolic 
queues queues queues queues 


Program A at Site 1 is the sender. ProgramB et Site2 is the receiver. 


CNC Description for BSC Link-up 


LINE LNnn, CLOSE; LINE LNnn, CLOSE; 
STATN STA1, 1; STATN STB2, 23 


TERMNL TB, TYPE =HL64, STYPE =CPU, TERMNL TA, TYPE =HL64,STYPE =CPU, 
ASSIGN = QA, AUTO; ASSIGN = QB, AUTO; 


QUEUE QA,...,RESTART; QUEUE QB,-«. , RESTART; 
QUEUE TB,e++ ,CTLRST; QUEUE TA,... ,CTLRST; 


In the CNC description of NDL commands, see Section V, the names of the 
program queues and terminal queues are the physical-queue-names. 

The lines described with CLOSE require both the site network operators 

to establish the link-up thru the command RT LNnn at the respective sites. 


Run-time JCL 


QASSIGN IN1,QA, IN; QASSIGN IN2,QB, IN; 
QASSIGN OUT1,TB, OUT; QASSIGN OUT2,TA, OUT; 


The $QASSIGN statement relates the symbolic queues to the physical queues. 
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The operation of the BSC link-up depends on the nature of the communication 
established and the recovery protocol : 


e interactive communication 


e unidirectional communication 


e recovery protocol 


Exchanges of data will take place in the 2 
directions successively from Program A to 
Program B and vice versa. 

The link-up must be established before the 
2 applications are launched. 


As in the case of file transfer, the sender 
application can be launched first provided 
its output queue TB, in the preceding 
diagram, is on disk with enough space. 


In some cases the rate at which the output 
queue TB is being filled in by the sender 
Program A is greater than the rate at which 
the output queue is being emptied to the 
receiver Program B. When this happens as in 
file transfer from magnetic tape, the sender 
Program A will encounter ''queue-overf low" 
incidents. 

To avoid such incidents, the sender program 
should issue a call to a system procedure to 
become temporarily suspended for a specified 
lapse of time before attempting another SEND 
to the output queue TB. Transfers from the 
output queue TB to Program B proceed un- 
affected. 

A "loop on the SEND statement has the effect 
of a temporary suspension, altho this method 
is not advised, since it takes up too much 
CPU time, see "Optimizing MCS COBOL Applica- 
tions" later on in this section. 


In the case of 2 remote applications where 

the link-up is used for a 1-way transfer, 

recovery protocol uses the system checkpoint 

and restart facility. . 

A recovery mark is emitted by the sender 

application each time-it takes a checkpoint. 

When the receiver application receives the 

recovery mark in the form of a control mas- 

sage, it in turn takes a checkpoint. 

Restart is always initiated by the sender 

application 

In order to implement the restart facility, 

- Program queues must be defined with the 
RESTART option 

- Terminal queues must be defined with the 
CTLRST option 

Recovery protocol is defined in terms of 

- Recovery on the emission side 


= Recovery on the reception side. 
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Programming Normal Message Flow 


Site 1 aa at ae Site 2 
Program A P 


rogram B 


call checkpoint 
test MOD 


SEND (''><CTLCKPOO'') EMI 
before sending data, program A takes 


first checkpoint to send control mes- 
sage showing checkpoint numbered ''00". 


RECEIVE 


call checkpoint 


MOD = 00 first message received is checkpoint 


numbered "00's; program B takes its 
own first checkpcint; both check- 
points have initial value "00". 


@)SEND (data) }EMI|Ecr } 


program A sends 1 or several files 
terminated by appropriate indicator. 


(6) RECEIVE 


[ program B receives data] 


call checkpoint 
test MOD 
SEND (''><CTLCKPnn") EMI 


program A takes sequentially numbered 
checkpoints to send as control messages. 


RECEIVE 


call checkpoint 


MCD = 00 


on receiving the checkpoint, program 
B takes its own checkpoint; numbers 
of both checkpoints match 1-to-1l. 


(SEND (data) SEMI] EcI} 


(@) RECEIVE 
call checkpoint 
test MOD 
SEND (''><CTLCKPnn"') EGI 


program A takes checkpoint; to indicate 
end of transmission, control message 
is sent with EGI. 


RECEIVE 
MCD = 00 
call checkpoint 


on receiving the checkpoint with EGI, 
©) end of normal transmission program B takes its final checkpoint. 


Recovery on the Emission Side 


- calling checkpoints 


Each transmission is started with a checkpoint call. On return of the 
call, the output parameter MOD is tested for either normal transmission, 
MOD=00, or restart after an abort, MOD#00. 


- using the H_CK_UCHKPT run-time package 


1 In the DATA DIVISION declare as follows : 


77 MOD COMP-2. 
77 CKINF PICTURE X(32). 


2 In the PROCEDURE DIVISION, code as follows ; 


CALL "H_CK_UCHKPT" USING MOD, CKINF. 


- normal transmission, MOD =00 


- image of control message at start of and during session 


SEND (''><CTLCKPnn) EMI | , where nn is sequentially numbered 
from OO thru 99. 


- image of control message to terminate session 


SEND (''><CTLCKPnn) EGI » for nn, see above 


Control messages are used to head data flow During a session, one or 
several files can be transmitted, each file being terminated with an EGI. 
To allow for recovery, the sender application takes checkpoints at suit- 
able and regular intervals, and checks that MOD=O0O in order to continue 
normal transmission. The checkpoint is then sent as a control message to 
head the next stream of data flow When the emission of a checkpoint has 
been completed, the system will release the disk space related to all the 
messages sent since the last valid checkpoint. 


The maximum number of disk blocks which can be retained between 2 check- 
points on emission is given by the algorithm 


n= (QDBLKSZ — 4) + 2 , where QDBLKSZ is the disk block size in 
bytes, see GENCOM command. 


See "MAM Tuning" in Section V. 


Restart of Application on Incident 


Site Il Site 2 


Program Ke Program B 


(SEND (data) }eM1|EcrT! 
(@) RECEIVE 


call checkpoint 
test MOD 
SEND ("><crLeKr (13) 


RECEIVE 


call checkpoint 


MOD = 00 


SEND (data) }EMI|EGT} 


step abort 
cr 
system crash 
occurs 


MOD # 00 


SEND (''><CTLRST 


the number of "restart" control 
is the same as the last valid check 
point sent in step 2. 
(d) RECEIVE 


on receiving the "restart" control, 
program B sets the "Status register"! 
to 10,000 to denote "abort/crash". 


| | STOPRUN 
SEND (d EMI| EGI 
@ a asi | (@) RECEIVE 
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For transparent mode, the sender application must only take a checkpoint 
at the beginning of transmitting a file and not during transmission 


- image for transmission in transparent mode 


("><CTLCKPnn"') EMI 
) EM 


("'><u06"' data 


pees 
e 


(data) {emr|zcr} 
SEND (''><CTLCKPnn'') EGI , to terminate the session 


e reStart after an abort/crash, MOD #00 


- image of restart control message 


SEND (''><CTLRSTnn"') EMI » where nn is the number of the last 
valid checkpoint sent. 


The "restart" control message can be emitted from 2 sources, 
- the sender application in the case of a step abort 
- the system, in the case of a system crash for remote communications. 


The "restart"! control message serves to warn the receiver application that 
all messages sent since the last valid checkpoint will be re-sent. 


If at the time of system restart, the sender application is also to be re- 
Started, then the receiver application will see 2 restart phases in the 
following sequence, 

- firstly, the restart control message from the system 

- then the restart control message from the sender application. 


e reStart after a line failure 


A line is closed by the system if failure occurs 
- either due to a malfunction in the link-up 
- or at the receiver site. 


The line can be re-opened by the network control command of the format, 
RT LNnn, where nn specifies the line. 


The effects of this command on a BSC line are, 

- the line will be re-activated 

- the control message '><CTLRSTnn" (ETB) will be sent 

- the terminal queue will be restarted from the last valid checkpoint 
indicated by nn of the restart control message. 


Transmission will resume on successful emission of the restart control 
message. Operator intervention at both sites may be required. 
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Sender Application Absent 


Situation at Failure 


" ><CTLCKP 4" "><CTLCKP , "! 


current first message following 


head-of - queue "><CTLCKP 4" 


end-of-queue 


Situation at Restart 


"> <CTLCKP , " "> <CTLCKP 


a 


iy "><CTLRST_," 


current this restart message will 
head-of ~queue head transmission 


Sender Application Present 


Situation at Failure 


end-of -queue 


SEND " ><CTLCKP . a 


! ia 
a we ><CTLCKP, 


Application 
current current first message following 


tail-of-queue head-of -queue "><CTLCKP |" 


Situation at Restart 


"><CTLRST, ,,!' '><CTLCKP, ,,'' '"><CTECKP,."" '""><CTLRST, |" 
| i+1 a itt i a 
Application 
SEND | 
restart from Pee currént this restart message will 
checkpoint (i+1) poceae head-of-queue head transmission 


Recovery on the Reception Side 


calling checkpoints 


Checkpoints are called using the H_CK UCHKPT run-time package, see 
"Recovery on the Emission Side". 


When the receiver application receives the control message ''><CTLCKPnn", 
it calls a checkpoint. The checkpoint called has the same sequence number 
as the checkpoint from the sender application that triggered it. No ccn- 
trol message is generated by the receiver application. The checkpoint 
serves as a recovery marke 


e reception of restart message 


"Restart" is indicated by the control message '"><CTLRSTii" sent to the 
receiver application. 


The receiver application performs the following decisions on the sequence 
number "ii'' of the "restart" control message, namely, 


- If ii=nnti1, where nn is the sequence number of the last checkpoint 
called by the receiver application, then the "restart" control message 
is treated as a checkpoint and the response of the receiver application 
is to call its own checkpoint and continue with normal transmission. 


- If ii=nn, then the receiver application must reStart from its current 
checkpoint. 
To do this, the application sets the STATUS register to an abnormal 
value, say 10,000, and then issues a STOPRUN. 
The application will terminate abnormally, and the system operator will 
have to restart the application 


- using the H_CBL_USETST run-time package for setting the STATUS register 


1 In the DATA DIVISION declare as follows : 


77 STATUS COMP-1. 


2 In the PROCEDURE DIVISION, code as follows : 


MOVE 10000 TO STATUS. 
CALL "H CBL USETST" USING STATUS. 


3-29 


« application restart 
The application is restarted from its previous checkpoint. 
Restart does not affect the sender application. 
The following events take place on SyStem reStart after a crash, 


The system will reset the receiver application and its program queues 
to their previous checkpoint state. 


- The terminal queue related tc the 3SC line is empty. 


- The line is re-activated by the network command RT LNnn, where nn sre- 
cifies the line. 


Operator intervention at both sites may be required to re-activate the 
line. 
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EXECUTING COMMUNICATIONS APPLICATIONS 


Preparing and running communications applications involves, 
« Preallocating a disk queue file 
« Linking MCS COBOL programs 
« Executing a communications step 
. Optimizing MCS COBOL applications. 


Preallocating a Disk Queue File 


If queues are to be held on a disk, a file must be preallocated on a disk Disk 
queueing is the default option of the QUEUE command, see Section V. 


Preallocating a disk file is performed 
« Using the extended JCL statement $PREALLOC, see Data Management Utilities 
Manual 
« Before H_CNC utility is executed since the disk queue file must be pre- 
formatted as a result of network generation. 


If the file is to be modified, e.g., altering the file size, the following 
procedure is performed in the sequence given, 
» The file is deallocated by either method, 
- using the extended JCL statement $DEALLOC 
- declaring MAM=NO at system initialization 
- It is then preallocated using $PREALLOC 
« H_CNC utility must then be run to update the system tables with the new file 
information. 


The disk file cannot be deallocated 
- If it is already defined for a network currently in use 
« If MAM=YES or MAM=REFORMAT was declared at system initialization, thereby 
allocating the file to a system process group. 


Example of Preallocating a Disk Queue File 


$JOB ALLOCDQ, USER = UNAME, PROJECT = WAGE; 


PREALLOC DQUEUE, EXPDATE = 365,DEVCLASS = MS/M400, 
GLOBAL = (MEDIA =VOL1,SIZE=5), 
BFAS = (SEQ = (BLKSIZE = 500, RECSIZE = 500) )3; 


$ENDJOB; 


Syntax concerning parameters in $PREALLOC : 


« The external file name DQUEUE must be specified in a $ASSIGN statement at 
H_CNC step execution. 


« The size of the file specified in the example as 5 cylinders is subject to 
limits of the device class, see Section V. 


» A disk queue file must be a single-volume file for which the starting 
cylinder cannot be specified, hence GLOBAL must be used. 


« The parameter group BFAS = (SEQ= (BLKSIZE =500, RECSIZE=500)) should be spe- 
cified as indicated. 
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Linking MCS COBOL Programs 


An MCS COBOL program is compiled using the standard $COBOL statement, see COBOL 
User Guide. 


Compile units (cu) of the MCS COBOL program are linked by the $LINKER statement 
to form communications load moduies. 


Linking an MCS COBOL Program 


$JOB job-name,USER=user-name, PROJECT = project -name; 


SYS. HCULIB 
LIB CU, INLIB1= § TEMP 
(simple-file-description) 
TEMP 
(simple-file-description) | 


, INLIB2 = } 


_ }\ TEMP ; 
| suas = ahaa | ; 


LINKER load-module-name [ ,ENTRY = cu-name | 


TEMP 
(simple-file-description) 


re : 


the following input enclosure is to link a multiprocess load module 
$INPUT input-enclosure-name3 


ENTRY =STUSERS, to enter & start MAM 


STARTASG = (PRIVATE = 8,SHARE=A), for executing calls thru 
ser-specified entr oints 
LINKTYPE = BMAM, oan ae eer yP 


TASK = (USER1, START = STUSER1), 
REPLACE = (DUMMY, cu-name1,CU =STUSER1), 


TASK = (USER2, START = STUSER2), 


TASK & REPLACE 
REPLACE = (DUMMY, cu-name2,CU =STUSER2), 


to be specified 
for each user process 


TASK = (USER6, START = STUSER6), 
REPLACE = (DUMMY, cu-name6, CU = STUSER6), 


$ENDINPUT3 


$ ENDJ OB; 
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Syntax for JCL used to link an MCS COBOL program : 


. $LIB statement 
- specifies the system library SYS.HCULIB containing the MAM run-time 
package 
- specifies the libraries containing the user compile units (cu) to be linked 
- describes the search path to the Static Linker 


- for details of parameters, see Library Management Manual. 


« $LINKER statement 
- OUTLIB specifies the library in which the load module is to be stored; if 
the argument TEMP is chosen, then linking and load module execution takes 
place within the same job. 
- Parameters applicable to a monoprocess load module : 
© ENTRY specifies the entry point to the program; the default entry point 
is the load-module-name. 
° COMFAC identifies the application as a monoprocess load module. 
- Parameters applicable to a multiprocess load module : 
° COMFILE names the input enclosure required to link a multiprocess load 
module. 


« input enclosure statements 
- ENTRY, STARTASG and LINKTYPE must be entered exactly as indicated with the 
parameters given. 
- TASK statement 
° USERn is used by MAM system procedure to start the indicated process in 
the order from USER1 thru USER6, where appropriate. 
- REPLACE statement 
© cu-namen defines the entry point in the program which is to be linked to 
the process name USERn in the corresponding TASK statement. 


Example of Linking a Monoprocess Load Module 


$JOB LINK1,USER = UNAME,PROJECT =ACCT; 
LIB CU, INLIB1 =SYS. HCULIB, 


INLIB2 = (UCULIB, DEVCLASS =MS/M400, MEDIA =VOL1); 


LINKER MAM1, 
OUTLIB = (ULMLIB, DEVCLASS =MS/M400, MEDIA =VOL1), 
COMFAC; 


$ENDJOB; 


Syntax in example of linking a monoprocess load module : 


- $LIB statement 
- UCULIB is the compile unit (cu) library on the volume VOL1 containing the 
user program 


e $LINKER statement 
- MAM1 is the load-module-name and is also the entry point to the user pro- 
grate 
~ ULMLIB is the user ioad module library on the volume VOL1 in which the load 
module is to be stored. 
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Example of Linking a Multiprocess Load Module 


$JOB LINK2,USER = UNAME, PROJECT= WAGE; 


LIB CU, INLIB1 =SyYS. HCULIB, 
INLIB2 = (UCULIB1, DEVCLASS =MS/M400, MEDIA = VOL1), 
INLIB3 = (UCULIB2, DEVCLASS =MS/M400, MEDIA = VOL1); 


LINKER MAM2, 
OUTLIB = (ULMLIB, DEVCLASS =MS/M400, MEDIA = VOL1), 
COMF ILE = *LINK; 


$ INPUT LINK; 


ENTRY = STUSERS, 
STARTASG = (PRIVATE = 8, SHARE=A), 
LINKTYPE = BMAM, 


TASK = (USER1, START = STUSER1), 
TASK = (USER2, START = STUSER2), 


REPLACE = (DUMMY, DATCOLL, CU = STUSER2) , 
REPLACE = (DUMMY, INQRESP, CU = STUSER1), 


$ENDINPUT; 
$ENDJOB; 


Syntax in example of linking a multiprocess load module : 


- $LIB statement 
- UCULIB1 and UCULIB2 are the compile unit libraries on the volume VOL1 
containing the user programs. 


« $LINKER statement 
- ULMLIB is the user load module library on the volume VOL1 in which the 
multiprocess load module MAM2 is to be stored. 


» input enclosure statements (sequence of statements is not significant) 
- REPLACE statement 
° DATCOLL is an entry point to the user program which is.to be linked to 
the process USER2. 
© INQRESP is an entry point to the user program which is to be linked to 
the process USERI. 


Executing a Communications Step 


A communications step is executed like any other GCOS job step. The only 
difference is the $QASSIGN statement which is required in the JCL for the MCS 
COBOL step. Points to note in specifying run-time JCL with $QASSIGNs are : 


- Any other output queues used by the application in the example given in 
SQASSIGN are implicitly specified. 


» In the case where the application uses disk queues, no $ASSIGN statement is 
required for the disk queue file because the file is opened at system level 
and is therefore sharable by all process groups. 


S$QASSIGN 


Definition 


The $QASSIGN statement performs the following, 

Defines the symbolic queues and subqueues, where applicable, used by the 
program 

Establishes a correspondence between the symbolic queue or sSubqueue and the 
extérnal-queue-name specified at CNC generation, see Section V 

Identifies the processing mode of the queue with respect to "send!" and 
"receive" actions 

- Allocates queues (input and optionally, output) to the step. 


Format of Statement 


QASSIGN symbolic-queue-name . symbolic-subqueue-name | » external-queue-name-1 


= | LIN 
>» ) LNOUT access =} EN » REPLY = external-queue-name-2 ; 
OUT 


Parameter Descriptions 
external-queue-name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 


symbolic-queue-name 
- the name of the logical queue defined in data-name-1 of the CD area of the 


MCS COBOL program. 


symbolic-subqueue-name 
- applicable only in the case of input queues and is the name given to the 
partitioning of the logical queue defined in data-name-2 of the input CD 
area of the MCS COBOL program 


ACCESS 
- applicable only to input queues partitioned into subqueues and specifies 

the way in which the subqueues are to be scanned in a "receive'! action, 

as follows, 

LIN : on each RECEIVE statement to the queue, the search begins with the 
first Subqueue Specified, ieee, linear, which is the default value. 

RR : on each RECEIVE Statement to the queue, the search resumes at the 
subqueue immediately following the subqueue that provided input data 
for the last RECEIVE statement issued, ieee, round-robin 


IN 
- applicable only to program queues and allocates the queue to the step in 


input processing mode, which is the default value. 


INOUT 
- applicable only to program queues and must not be specified for subqueues. 
Allocates the queue to the step in input and output processing modes. 


OUT 
- must not be specified for subqueues; allocates the queue to the step in 


output processing modee 


REPLY 
- applicable only for application-to-application communications and must be 


specified with either INOUT or OUT modes, see "Usage Rules", overleaf. 
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SQASSIGN 
continued 


Usage Rules 


1. The order of the list of subqueues within a symbolic input queue is deter- 
mined by the order of $QASSIGN statements within the step enclosure. 


2. The maximum number of $QASSIGN statements permitted within the step enclo- 
sure is 24. 


3. The ACCESS parameter is only relevant in the first $QASSIGN statement 
defining a queue Structure, ieee, subqueues within the queue. 


4. A $QASSIGN statement is mandatory for each input queue associated with the 
program. 
For output queues, the $QASSIGN statement is optional. 


5. REPLY defines another program queue which is identified as the source of in- 
put messages in the destination application's input CD. 
The REPLY facility enables the destination application to answer back, using 
in its turn the program queue thus defined as "destination". 


Example of Run-time JCL with $QASSIGNs 


$JOB TELECOM, USER = UNAME, PROJECT = ACCT, CLASS = H; 
STEP MAM3, (ULMLIB, DEVCLASS =MS/M400,MEDIA =VOL1); 


QASSIGN INQ. SUB1,PRG1,ACCESS = RR; 
QASSIGN INQ. SUB2, PRG2; 
QASSIGN INQ. SUB3, PRG3; 
QASSIGN INQ. SUB4, PRG4; 


eer QASSIGN OUTQ,TRM1, OUT; relates symbolic-output-queues 
BrouP © ) QASSIGN OUTW, TRM2, OUT; to terminal-queues 
ENDSTEP 
$ENDJOB; 


these 4 $QASSIGNs 
identify a queue structure 
for symbolic-input-queue INQ 


group a 


Syntax in example of run-time JCL with $QASSIGNs : 


- $JOB statement 
- CLASS =H is recommended for a communications step to ensure adequate 
response time in a multiprogramming environment. 


- $STEP statement 
- MAM3 is the multiprocess load module linked and stored in a previous 
session in the user load module library ULMLIB 


- $QASSIGN statements 
- group a : each symbolic-subqueue corresponds to a unique external-queue- 
name, ieee, SUBn to PROGn, specified during CNC generation and 
will be scanned in "round-robin" in the order specified. 
- group b: the symbolic-output-queues OUTQ and OUTW are associated with 
their respective terminal-queues TERM1 and TERM2. 
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Ot fare END 


Optimizing MCS COBOL (MAM) Applications 


General recommendations for optimizing MCS COBOL programming include, 


- using the RECEIVE verb (not qualified by the NO DATA clause) 
One of the 2 following conditions will occur, 


- If at least 1 message is queued, then it will be delivered into the 
user specified working area, and control is returned to the application 
program. 


-~ If the queue is empty, MAM suspends the application program until a 
message arrives in the queue. 
When a message arrives, it is delivered into the user specified working 
area, and control is then returned to the application program. 


- uSing the RECEIVE verb with NO DATA clause 


RECV. 


RECEIVE CD-IN INTO BUFFER NO DATA N-DATA. 


N-DATA. 
* IF NO DATA GOTO RECEIVE 


GO TO RECV. 1 


If a message is available in the queue, it is delivered into the 
user specified working area, 

- control is returned to the application program, and 

» the NO DATA condition is bypassed. 


If no message is available, the NO DATA condition entered and the 
application will loop on this condition until a message arrives in 
the queue, thereby causing the application program 
to occupy all the CPU time not used by BINS or the system, and 
therefore 
to prevent the execution of any batch program, and consequently 
to reduce thrupute 


RECEIVE with NO DATA should be used under the following conditions, 


- To scan a queue while executing another process or while waiting for 
the occurrence of other events 


- To include in the NO DATA loop a call to the run-time package 
H_TM_USETTM to allow the application program to be suspended for a user 
specified time before being re-activated. 
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« using the ACCEPT verb 


ACCPT. 
ACCEPT CD-IN MESSAGE COUNT. 


IF MSG-CNT =O GO TO ACCPT. 


1 If the message count is not zero, the application program 
continues normal processing. 


2 If the message count is zero, the MSG-CNT=O condition is entered 
and the application will loop on this condition until a message 
arrives in the queue to update the count. 

The result of this looping is 

- to cause the application program to occupy all available CPU 
time, 

- to prevent the execution of any batch program 

e to reduce thruput. 


ACCEPT should be used under the following conditions, 


- To aScertain the number of messages in a queue while executing another 
process or while waiting for the occurrence of other events 


- To include in the loop, in the example given, the MSG-CNT=O condition, 
a call to the run-time package H_TM USETTM to allow the application 
program to be suspended for a user specified time before being re- 
activated. 


» using the H_TM USETTM run-time package 


1 In the DATA DIVISION declare as follows : 


O1 T COMP-2. » where T is specified in milliseconds 


2 In the PROCEDURE DIVISION, as in the loop, code as follows : 


CALL '"H_TM USETTM" USING T. 
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« handling several program queues 


As a general rule, most application programs handle only 1 program queue 
which is the "point-of-entry" for all data received by the program 


In some cases, the application program may have to handle several pro- 
gram queues if 
- an order of priority is to be established between more than 1 source 
of messages so that on ticular source can i 1 
time 
- the application program is to communicate with a complex of terminals 
and with either or both, 
° a process of the same application 


° another application program 


Scanning the different program queues: 
Consider 3 program queues, Q1, Q2 and Q3 in which the application is to 
receive messages. Ql has the lowest priority, Q3 has the highest. 


Solution 1: The application scans each queue in the order of priority 
indicated, ite, first Q3, then Q2 and finally Ql], by 
° looping on RECEIVE NO DATA successively for each queue 
° including in each loop a "wait-time" using the facility 
H_TM_USETTM. 


The drawbacks of this solution are, 

° if the 'wait-time' is too large, then the "turn-around" 
time will be too slow . 

° if the 'wait-time" is too small, then the application 
will loop on itself until a message became available, 
which would defeat the purpose of using H_TM USETTM 


Solution 2 : A queue structure can be defined thru the $QASSIGN state- 
ment in the run-time JCL in the following way, 


QIN 


Ql Q2 Q3 


In this case, the application program only has to issue a 
RECEIVE (without the NO DATA clause) to the queue QIN, 
without having to specify the individual '"sub-queues". 


The advantages of this solution are, 

° if no message is available in any of the "'sub-queues", 
MAM suspends the application, and processing will only 
resume aS soon as a mesSage arrives in any of the "sub- 
queues". 

° the RECEIVE command will indicate in the input CD from 
which '"'sub-queue'' the message has been received, and the 
application can then place whatever priority it wants on 
processing ite 
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SECTION IV 


MCS DATA FORMATS 


This section deals with the format of data sent to or received from a terminal 
by an MCS COBOL application program The data is held in the working area de- 
fined as the user buffer and accessed by the SEND and RECEIVE verbs. 


Data comprises, 


« Information data composed of characters corresponding to graphic symbols as, 
- numeric characters 
- alphabetic characters, both upper and lower case 
- special characters, including punctuation. and mathematical symbols. 


'. Control characters providing terminal management functions as, 
- editing or service functions, including carriage-return, tabulation; 
cursor poSitionings, ete, 
- auxiliary device commands, such as for the cassette handler 
- timing functions, including "fill" characters to allow for slow mechanical 
functions on any printer device 
- message delimiters, including trailers and VIP headers. 


The control characters are generated by 
» control touch-keys on the device, used either individually or in combination 
* a sequence of encoded characters. 


MARK REPRESENTATION 
Mark representation is a symbolic representation of data at user program level 
provided by MCS and uses the symbols >< to prefix 

« VIP headers 

e Control characters 


« Character-encoding 
e Repeat 


VIP Headers in Mark Form 


Format : ><UO3abc, where a = status, b = function-code-1, c = function-code-2 


Control Characters in Mark Form 


Format : ><ccc, where ccc = 3-letter control character symbolic representation, 
see "Control Characters and EBCDIC Values" 
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Character-encoding 


Format : ><Cab, where ab = 2-digit hexadecimal value corresponding to any char- 
acter including a control function, see "EBCDIC Values & Con- 
trol Characters" 


Repeat 


Format : ><Rnn, where nn = 2-digit decimal value dencting that the following 
character or hexadecimal value is to be repeated for as many 
times as specified. 


TRANSMISSION MODES 


Transmission from the terminal is in ASCII code, altho in the case of the BSC 
line procedure, such as BSC2780 terminals, transmission may be in EBCDIC code 
which is the Level 64 internal codes 


Translation from ASCII code to EBGDIC, and vice versa, is performed in the IURP 
or URP by means of the TCT (translation control table). 


The user buffer will contain the EBCDIC values of data input from the terminal 
or to be output to the terminale 


The transmission modes are 


- Input Normal Mode 
- Input Marked Mode 
- Input Unedited Mode 


- Output Normal Mode 
- Output Unedited Mode 


In the examples following, the conventions used in the data formats are, 
- For hexadecimal values, specified in internal EBCDIC code, double quotation 
marks "'" '" are used for enclosure 
- For graphic symbols, single-letter alphanumeric values are used 
» For control characters keyed in on the device or sent to the device, the 
3-letter code is used 
» Divisions within the buffer denote the value weighting of 1-byte 
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Control Characters & EBCDIC Values 


Line | Line Procedure | Line Procedure 

Hexe Hexe 

Control Character Code - Control Character Code 
VIP BSC TTY VIP BSC 


| ACK] ACKnowledge {25 | 1/ ) I jETBy End | 26 j2/0 T T | 
Transmission 
BO1| advance 1 page {OC O O- Block 
see also FFV 
ETX| End of TeXt 03 1/0 t IT 
BO3j] advance 1 line |OD25] O 0) 0 
see also CRV LFV FFV| Form Feed OC 1/0 I/O 1/0 
NLV see also BOl 
BEL] BELL 2F 1/0 na I/O|/FSV| File Separator | 1C 1/0 I/O 1/0 
VIP terminals, |5F na I/O na | 
BEIwederates SF GSV| Group Separator|1D |1/0 1/0 1/0 
BLK| BLink sr. {1/0 1/0 1/0 HTV Horizontal Tab | 05 I/O 1/0: 1/0 
VIP terminals, LFV| Line Feed 25 {1/0 I/O 1/0 
see also BEL 
NAK} Negative 3D 1/0 I I 
BSV| BackSpace 16 1/0 TfO° I/O AcKnowledge 
CAN| CANcel 18 I/O T I |[NLV] New Line OD25|1/0 1/0 -1/0 
see also BO3 
CRV| Carriage Return] OD 1/0 E/O- Tf 0 CRV LFV 
DC1| Device Control 1}11 | 1/0 1/0 1/O|[NUL| NUL1 00 |1/0 1/0 1/0 
DC2} Device Control 2)12 | 1/0 1/0 I/OlfRSViRecord Separator; 1E {1/0 I I 
forward space ; 
(UIP cect nats) SIV} Shift In OF 1/0 I i 
DC3] Device Control 3}13 | 1/0 I/O 1/0 eM ene ee oe OE are ee 
DC4| Device Control 4}3C 1/0 I/O I/0 SOH/ Start Of Header | 01 1/0 : : 
0 
DEL| DELete 07 |1/0 1/0 1/0)SF¥| SPace 40 | 1/0 1/0 T/ 
DLE] Data Link Escape|10 1/0 a ni se ea ae ae ve 1/0 y : 
EMV|End of Medium {19 {1/0 1/0 1/o}°UP) SUBSeitute BE Ieee me 
; r QO T 
ENQ| ENQuiry oD 1/0 I t SYN SYNchr onous 32 I/ r 
as idle 
BOT Ene 4 ; a 1/@ : . USV| Unit Separator | 1F 1/0 I I 
Transmission = os 
lertastay ance ad 9 1/0 . : 
ESC] ESCape 27 |1/0 Toto |S ctee aeP a fa 


4-03 


EBCDIC Values & Contrcl Characters 


Control Character 


NUL1 

Start Of Header 
Start of TeXt 
End of Text 
not reserved 
Horizontal Tab 
not reserved 


DELete 


not reserved 


Vertical Tab 


advance I page 
Form Feed 


Carriage Return 


advance 1 line 
New Line 


Shift Out 
Shift In 
Data Link Escape 
Device Control 1 


Device Cont rol? 


Device Contrel 3 


not reserved 


BackSpace 


Control Character 


CAN 


not reserved 


CANcel 


EMV End of Medium 


not reserved 


File Separator 
Group Separator 
Record Separator 


Unit Separator 


not reserved 


Line Feed 
End of 
Transmission 


Block 


ESCape 


not reserved 


ENQuiry 
ACKnowledge 
BELI 

not reserved 


SYNchronous idle 
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Control Character 


not reserved 


End Of Transmissicn 


not reserved 


Device Control 4 


Negative 
AcKnowledge 


not reserved 
SUBstitute 


SPace 


not reserved 


not reserved 


BLink 
(for VIP only) 


not reserved 


* h signifies any 
hexadecimal unit 


EBCDIC Character Set & COBOL Collating Sequence 


EBCDIC 
graphic Explanation of abbreviations : 
| | COBOL : 
- EBCDIC - EBCDIC hexadecimal value 
00 1 @EBCDIC raphic - raphic symbcl 
O1 2 graphic ee GBPeP grap y 
02 3 COBOL - COBOL - COBOL collating sequence 
ie ) : 2c 45 @ EBCDIC 
O5 6 2D 46 graphic 
oe mq Be 47 COBOL 
07 gMcr| | 48isal | 85 [fescprc 
08 hay 49B55 86 graphic _ 
ne me EE! 508 56 87 COBOL 
OA} | 11 - _ 7) | 88878} |121 Rescprc 
OB 1285), a E gM 79|*)122 graphic 
ere 1385. a EL 90 7A|: 1123 COBOL 
7B #1124 
OD} | 4B 36] | ssMmftty 72 24 Bon! 1155 Mf epcpic 
OE 15 5Bi$}] 929 7C1@/125 
af 56 ; OB 156 graphic 
OF 16 5C|*| 939% 7D|/ [126 
hs cl 1157 COBOL 
is 1728 579B5D})] 94M 7EI=|127H oO} tis. 
39 58 MSEl; | 9OSM7F/"1128 B8| 1185 M@EBCDIC 
4 18 9F]| 1159 — 
3A 59B5Fi7| 96 BO} | 186 graphic 
12 19 80| 1129 9F| | 160 
3B 60 BA! 1187 [CoBOL 
13 208 ae oe 978 81)a/1308 | | 161M ee iiaa 
14 21 61//| 989982 1b]131 be D3|L] 212 EBCDIC 
3D 62 A1|~|162M Bc! |189 
15 92 62 99 83 1c] 132 D4|M] 213 
3E 63 A2|s|163—§ BD} |190 
16 23 Bap 64 O3| | 100 84)4/133 Bs |, liege! (101 2l|N 214 
17 24 64) 1101985 ]e]1340 7 | lies Marl too D6|0/ 215 
3 fe 40|V| 65965] (102 M86 |£/135 Me | ace D7| P| 216 
41| | 66 M66] |103 887 |e | 136 co} {}193 
19) | 2685] | 67 fez! |104 sea lbeea TLINETS bead bone 
1A 27 88 1h|137 MA7 |x| 168 D9}RI] 218 
in| | 23>} | 8 39141138 C21B/195 Boal 519 
44 69638] |105 A8|y| 169M c3| Cc} 196 
1C 29 BA| 1139 DB] |220 
45 70 M69! |106 A9|z1170M c4|D| 197 0 
1D 30 8B| 1140 DC} }221 
46 71 M6Al} 1107 AA| |171§C5/E] 198 1 
1E 31 8c] |141 DD] }222 
47 72 M6B{, | 108 AB| |172—§C6/F/199 y) 
1F 32 2 8p} 1142 DE] [223 
661%} 109 AC| |1739§c7|G|200 3 
48 73 8E| 1143 DF] |224 
20 3306 ah 6D}_}110M oe} tia go> 174 wa 4 
21 340. a 6E|>]111 AE| |175 ol aians EOI\|225 5 
22| | 35 ¢ 6F121112M 90] |145 MAF] | 176 E1| |226 6 
93| | 36M ee it| 26 91]; [146 CA} 1203 Bol s|227 7 
4cl<| 77 70] |113 BO| |177M§ CB] | 204 
24 37 92 1k |147 E3|T|228 
4D/(| 78 71] 4|114 B1| |178Mccl| | 205 8 
25 38 93 |11148 E4|U|229 
4EI+| 7972] [115 B2{ |179McD| | 206 9 
26 39 94 1m}149 E51V| 230 
4Fi| |} 8073] |116 B3| |180M CE] |207 
27 40 95 |n|150 E6)W]231 
74) |117 B4| 11810 CF| | 208 
50l&} 81 96 |o}151 E7|X|232 
28 410 39 M2] 1218 B os |, las. B5| | 1828 iG 
29 428 33 M20} [219 P EES] Pet antes 
2A 43 0. 34 M27 | | 420 98 ]q|153EB7| | 184 olen E9| Z| 234 
2B 44 99}r|154 EA| 1235 


4-05 


Translation from EBCDIC to ASCII 


EBCDIC 
ASCII 


00} OO @ EBCDIC 
01)01 ASCII 


02/02 03] ssf esebuc 
ASCII 


2c] 3c| 
04) CR ol os ABI EBCDIC 


09 OP 2B | 06 ASCII 
06 | 86 fF] ° 
07|7F ADM 79|60[Mf EBCDIC 


30} 90 AE 7A] 3A ASCII 


08 | 97 
A 7B 
09] 8D a ag q a 9D| CE@# EBCDIC 


OA| 8E B33} 93 158] BOM 7C| 40M 9E| cF ASCII 
Bl 7D| 27 
OB] OB oF] DO cere 


ay 
34] 94 5D 7E| 3D 
males Pelee] Fale faaees PRieel Celtel MMi 
OE! OE 36 | 96 418 DE|F2 @ EBCDIC 


24 @ 80/C3 Hf A2) 73 
oF | OF 37|04 70M 381 A3|74 ie DF | F3 ASCII 


38] 98 3B 82 0|5cM FBI FB 
10) 10 BE 39] 99 SEM 83 sas 4448 E1| OF 
11/11 elo A5| 76 me Pape indice 
Ape) bese op 84 A6|77 1 Bes | cag FD (ED 


13113 2F @ 85 A7|78 47 FE|FE 
14| 9p 30}14 B2 @ 86 agl79 E4|)55@ FF|FF 
Spi B3 87 E5| 56 
15/85 3E| OF A9|7A 56157 
16 | 08 3F/ 1A B48 88 AA|D2 £7158 

17|87 B5 89 AB| D3 


18/18 40} 20 BO @ 8A ACIDS E8159 

41)A0 B7 8B E9|5A 
19/19 421A1 AD;D5 EAIF4 
1A] 92 43142 B8 @8C AE| D6 EBIFS 
1B | 8F BOB 8D AF |D7 


44)A3 7CHS8E EC| F6 
ae 45)A4 2C BSF Boe ED|F7 
1D} 1D B1\D9 

46]A5 EE|F8 
1E|1E 47/A6 25 90 B2|DA EFIF9 
1F|1F 5F 91 B3 | DB 


48 |A7 3E 92 FO| 30 
20180 Bp olag 3F 93 ad tage F1/31 
21/81 Bl sp ed (ee F2/32 
22182 BAM 94 36 | DE 


23/83 Po 1 2= 2B W 95 |(6EMB7|DF F3)33 


val aa ly 20 [3¢ BCH 96 ee F4|34 

4p |28 BD 97 F535 
25)0A B elon ed F6 | 36 
26/17 BE M98 BA|E2 le 
27/18 BF 99 BBIE3 


28188 50 CO 9A Bc| E4 FS1o0 

Sal C1 9B F9}39 
29139 52 BD|E5 FAIFA 
2A|oA C2 9C BE} E6 
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ASCII 
EBCDIC 


00|00 @ ASCIT 


BO1|Oig 


02 
03 


04 
05 
06 
O07 


08 
09 
OA 
OB 


OC 
OD 
OE 
OF 


10 
11 
t2 
13 


14 
15 
16 
Le 


18 
19 
1A 
1B 


1C 
1D 
1E 
1F 


20 
24 
22 
Zo 


24: 


25 
26 
a 


28 
429 
2A 


02 
03 


37 
2D 
2E 
ZF 


16 


105 


25 
OB 
OC 
OD 
OE 
OF 


10 
11 
12 
13 


3C 
3D 
J 
26 


18 
19 
SF 
Zt 


1G 
1D 
1E 
1F 


40 
4F 
7F 
7B 


5B 
6C 
50 
7D 


4D 
3D 
5G 


2B 


2G 
2D 
2E 
2F 


30 
31 
32 
a2 


34 
35 
36 
37 


38 
39 
3A 
3B 


3C 
3D 
3E 
3F 


40 
41 
42 
43 


44 


45 
46 
47 


48 
49 
4A 
4B 


4c 


a 4D 


4E 
4F 


50 
om 
52 


Translation from ASCII to EBCDIC 


| EBCDIC 
SE ASCII 


6B 
60 
4B 
61 


FO 
Fl 
| F2 
F3 


F4 
ES 
F6 
By 


F8 
F9 
7A 
SE 


4¢C 
7E 
6E 
6F 


7G 
C1 
C2 
C3 


C4 
C5 
C6 
C7 


C8 
c9 
D1 
D2 


D3 
D4 
D5 
D6 


D7 
D8 
D9 


14 @ ASCII 
EBCDIG 


75 @ ASCII 
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76 
iy 
78 
80 


8A 
8B 
8C 
8D 


8E 
SF 
90 
9A 


OB 
9C 
9D 
OF 


OF 
AO 
AA 
AB 


AG 
AD 
AE 
AF 


BO 
B1 
B2 
B3 


B4 


135] 


Bo 
B7 


B8 
B9 
BA 
BB 


BG 


EBCDIG 


ASCII 
EBCDIG 


FB|FB 


FC; FC 
FD|FD 
FE/FE 
PRIEE 


Input Normal Mode 


The input normal mode is entered when 


- the TERMNL command is not specified with the IM parameter, ieee, "normal" is 
the default input mode 


« the TERMNL command is specified with the parameter IM=NL 

» the network command MTE specifying the terminal and the parameter INORM is 
keyed in 

- the terminal operator command $*$MTE specifying INORM is issued. 


Treatment of data in the normal mode is as follows, 


1. Headers, trailers and control characters are deleted from the user buffer. 


, 7 ee : |erx|zor| message keyed in on terminal 
Y ae ho 
ae | delete VA delete 


2. The character-encoding mark ><C is not transmitted; it passes the following 
2 hexadecimal digits as a 1-byte hexadecimal value to the user buffer. 


data transmitted to user buffer 


message keyed in on the terminal 


data transmitted to user buffer 


3. The repeat mark ><R is not transmitted; it repeats the following character 
or hexadecimal value as many times as specified. 


data transmitted to user buffer 


4. The sequence of the repeat mark followed immediately by a control character 
mark is deleted from the user buffer. 


ee ee er 


delete 


data transmitted to user buffer 
5. All other characters including the marks >< are passed to the user buffer. 
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Input Marked Mode 


The input marked mode is entered when 
» the TERMNL command is specified with the parameter IM=MK 
» the network command MTE specifying the terminal and the parameter IMARK is 
keyed in 
.- the terminal operator command $*$MTE specifying IMARK is issued. 


Treatment of data in the marked mode is as follows, 


1. VIP headers are translated into mark form and passed to the user buffer. 


transmission header converted 
to logical header by URP 


data transmitted to user buffer 


2. Control characters and trailers are translated into mark form and passed to 
the user buffer. 


message keyed in on terminal 


3. The character-encoding mark ><C is not transmitted; it passes the following 
2 hexadecimal digits as a 1-byte hexadecimal value to the user buffer. 
The repeat mark ><R is not transmitted; it repeats the following character 
or hexadecimal value as many times as specified. 


of 9 frwan| eran] mete data transmitted to user buffer 


4. The sequence of the repeat mark followed immediately by a control character 
mark is deleted from the user buffer. 


ee eee ee 
fo | a data transmitted to user buffer 


5e All other characters including the marks >< are passed to the user buffer. 
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Input Unedited Mode 


The input unedited mode is entered when 
- the TERMNL command is specified with the parameter IM=UN 
« the network command MITE specifying the terminal and the parameter INEDT is 
keyed in 
- the terminal operator command ¢*$MTE specifying INEDT is issued. 


Treatment of data in the unedited mode is as follows, 


1. VIP headers are translated into mark form and passed to the user buffer. 


transmission header converted 


logical header to logical header by URP 


data transmitted to user buffer 


message keyed in on terminal 


data transmitted to user buffer 


Input Message Flow 


1. VIP-headers 
data generated by the 
a b Cc terminal in the VIP 
line procedure header 


ASCII code 


transmission 


code conversion in 
URP using TCT 


EBCDIC code translated 
in BTNS buffer 


normal mode 


user marked mode 
buffer 


generated by MCS 


unedited mode 


2. Control Characters and Trailers 


normal mode 


user 
marked mode borear 


EIESEEsE 
refsefeferfen 


Bono 
Src 


unedited mode 


Input Message Flow 


continued 
3. Control Characters and Trailers in Mark Form 


data keyed in on 
terminal 


met m3c nWa5gu m5 magn mgdqu mgcn magn Wap moan ASCII code 
es transmission 


Mi 
code conversion in 
URP using TCT 

NN 7 


EBCDIC code trans- 
lated in BTNS buffer 


eepopepe 
whefopale 
eefapaye 
mje peer 


4, Character-encoding 


eefepaten 
ee befefor fer 
ESeo oy 
ee oferfon a 


normal mode 


user 


marked mode ee 


unedited 


tT! Ww 
6E mode 


data keyed in on terminal 


ASCII code transmission 


peepee pe 
aS 
ASCII to EBCDIC code conversion in URP 
using TCT 
Sr 
eefefo fale 
normal mode 
marked mode 
ehefota fe 


data in EBCDIC code stored in BINS buffer 


user 
buffer 


unedited mode 


Input Message Flow 


continued 


5. Repeat followed by Character-encoding 


d ; 
CS Se eye ee ee 
terminal 
Y i peed eorh re eee 2 Te 
N3RMPNgctPUg 9 v30"] 33m] sz] 3am] nage] magn mA5 ASCII code 
transmission 
7™ 
Cie. code conversion in 
URP using TCT 
Se 
Bg 
NBS" normal mode 
efana mt in 


oe ooo ow ow feo ott ot 


6. Repeat followed by Control Character Mark 


EBCDIC code translated 
in BINS buffer 


data keyed in on 
terminal 


fe foe [sofa efor fan foo] sce 
transmission 
7™ 
code conversion in 
URP using TCT 
N77 
reefer fen fee eofenfen 


suppressed normal mode 


EBCDIC code translated 
in BINS buffer 


Suppressed marked mode eee 


oor ow oo owe em wen 
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Input Message Flow 


continued 


7. Repeat followed by Graphic Symbol 


data keyed in on terminal 


pam se serfs asf] aor cote ernst 
Z7™ 
ASCII to EBCDIC code conversion in 
URP using TCT 


ere 
en] fanf erp 
eaten 
eee 
eel 


data in EBCDIC code stored in BTNS 
buffer 


normal mode 


user 


buffer marked mode 


"ROM unedited mode 


le 


Output Normal Mode 


The output normal mode is entered when 
e the TERMNL command is not specified with the OM parameter, ieee, "normal" is 
the default output mode 
« the TERMNL command is specified with the parameter OM=NL 
« the network command MTE specifying the terminal and the parameter ONORM is 
keyed in 
« the terminal operator command $*$MTE specifying ONORM is issued. 


Treatment of data in the normal mode is as follows, 


1. VIP headers can be provided in mark form to be passed to the terminal. 
The system provides trailers where none are specified by the user. 


data composed in user buffer 


user-specified header converted 
to transmission header by URP. 
in this example, the trailer is 
supplied by the system 


2. 1-byte hexadecimal characters representing control characters, as "05", are 
translated as 2 hexadecimal digits preceded by the character-encoding mark. 
1-byte hexadecimal characters not representing control characters, as "'F6", 
are passed directly without further process. 

Control characters in mark form are translated as control characters. 


data in user buffer 


data sent to terminal 


3. The character-encoding mark ><C is not transmitted; it passes the following 
2 hexadecimal digits as a 1-byte hexadecimal value to the terminal. 
The repeat mark ><R is not transmitted; it repeats the following character, 
hexadecimal value or control character as many times as specified. 


data sent to terminal 


4, All other characters including the marks >< are passed to the terminal. 


Output Unedited Mode 


The output unedited mode is entered when 
- the TERMNL command is specified with the parameter OM=UN 
» the network command MTE specifying the terminal and the parameter ONEDT is 
keyed in 
- the terminal operator command $*$MTE specifying ONEDT is issued. 


Treatment of data in the unedited mode is as follows, 


1. VIP headers can be provided in mark form to be passed to the terminal. 
The system provides trailers where none are specified by the user. 


data composed in user buffer 


user-specified header converted 
to transmission header by URP. 
in this example, the trailer is 
supplied by the system 


2. Control characters are passed to the terminal. 


data composed in user buffer 


data sent to terminal 


Output Message Flow 


1. ViIP-headers 


data in user buffer in 
_ EBCDIC code 


within the logical line 
procedure header 


translation by BTNS 


format is the same for 
normal & unedited modes 


EBCDIC to ASCII code 
conversion using TCT 


data sent to terminal in 
ASCII code within the 
line procedure header 


2. Control Characters and Trailers 


Note : "D5'' is not a reserved control character value 


data in user buffer 
in EBCDIC code 


normal unedited 


EBCDIC to ASCII code 
conversion using TCT 


data sent to terminal 
in ASCII code 


Output Message Flow 


continued 


3. Control Characters and Trailers in Mark Form 


Boe 
ron ne fesrfan fe 


translation by BTNS 


data in user buffer 
in EBCDIC code 


cs 
fe 


unedited 


4. 


EXKacaaes 
ower 


unedited 


referee 
Zo 


EBCDIC to ASCII 
code conversion 


pe 


aoe oo ena 
Teepe 


data sent to terminal 
in ASCII code 


Output Message Flow 


continued 


5. Repeat followed by Character-encoding 


data in user buffer 


N6OEMENACH pon tipo lupon 6EVEMAcrinegrpupgu pup gy in EBCDIC code 


translation by BINS 
se fefeolo fe 


EBCDIC 
£6 Zs 
su <> 
code 7, 
conversion 


an fae paar fae 


scree [an foofanfor fan 
renfe 
PERT 


to 
ents [> [<[e fof 
6. Repeat followed by Control Character Mark 


CEEPEPPCEPET: 
rr ee fer 


translation by BTNS 


normal unedited 


data in user buffer 
in EBCDIC code 


EBCDIC 
to 
ASCII 
code <-> 
conversion 
perf] ces see [vfsops soon foe [seus on 
| to oa | 
jefe] cents [SPefe pole > [<fe le fe 


Output Message Flow 


continued 
7~ Repeat followed by Graphic Symbol 


CEEE PT 
fo fon ero 


translation by BTNS 


data in user buffer 
in EBCDIC code 


normal unedited 


feof oe efor roerfen 
in 

EBCDIC to ASCII 

code conversion 


NC” 
aa feof Pana 
Piette Pte 


data sent to terminal 
a ee 
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Input 
Marked 
Mode 


Input 
Unedited 
Mode 


Out put 
Normal 
Mode 


Output 
Unedited 
Mode 


In the above table, the "escape'' character corresponds to 


VIP-header|! Trailer | 


deleted 


passes 
header in 
mark form 
><UO3abec 


passes 
header in 
mark form 
>< UO3abe 
) 


optionally 
user- 
provided 
in 
mark form 
><U03abec 


optionally 
user- 
provided 
in 
mark form 
><UO3abc 


Summary of Data Formats 


passes 
trailer 
in 
symbolic 
form 


passes 
trailer 
as 
entered 


system- 
provided 
if 
required 


system- 
provided 
if 


required 


Hexadecimal 
Control 
Character 
(ee go ''27'") 


deleted 
except for 

V= m4on 
P= +05" 


translates 
to 
mark form 


>< ESC 


passes 
hexadecimal 
value 
mo7qi 


translates 
to 
character- 
encoding in 
mark form 


><C27 


passes 
hexadecimal 
value 


mo7" 


Character- 


Encoding in 


Mark Form 
(ee Bes ><C27) 


passes 
hexadecimal 
value 
WOT" 


passes 
hexadecimal 
value 
noq" 


untranslated 
passes 


><G27 


passes 
hexadecimal 
value 
maz" 


untranslated 
passes 


><C27 


e The internal hexadecimal EBCDIC value "27" 
e The control character in mark form : ><ESC 
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Control 
Character in 
Mark Form 
(@s ge » ><ESC) 


untranslated 
passes 


><ESG 


untranslated 
passes 


><ESG 


untranslated 
passes 


>< ESC 


translates 
to 
hexadecimal 
equivalent 
noq7" 


untranslated 
passes 
>< ESC 


DATA REPRESENTATION 


GCOS 64 offers the MCS COBOL programmer several modes of representing data de- 
pending on, 
- the type of terminal to be uSed, eege, Special character set 
» the complexity of the control functions to be activated 
- the provisions to be made for a future transition of the program to TDS with 
the minimum modifications necessary to the program 


Data to be treated by the MCS COBOL program can broadly be categorized into two 
main groups, namely, 

« information data 

- control characters. 


The main difference between information data and control characters is that con- 
trol characters cannot be represented by graphic symbols. 


In the programming examples that follow, it is assumed that the parameters list- 
ed have been correctly declared and initialized in the data division of the pro- 


gram, 
- buffers, namely, INBUF and OUTBUF 
- CD parameters, CDIN and CDOUT. 


Information Data Representation 


The three ways in which information data is represented are, 
» graphic representation 
« COBOL collating sequence 
« mark representation 


GRAPHIC REPRESENTATION 


Problem 1 : 


To send the text 


* HERE IS DATA-ENTRY (78/03/29 VERSION) * 


Solution : 


The following coding may be used 
1 In the DATA DIVISION declare as follows 


77 START PIC X(41) VALUE ''* HERE IS DATA-ENTRY (78/03/29 VERSION) *'', 


2 In the PROCEDURE DIVISION code as follows : 


MOVE START TO OUTBUF. 
SEND CDOUT FROM OUTBUF WITH EMI. 
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Problem 2 : 


To check if the message received is STOP which requests termination of the ap- 
plication program 


Solution ; 


The following coding may be used 


1 In the DATA DIVISION declare as follows : 


O1 INBUF. 
O02 INB1 PIC X(2000). 
O02 INB2 REDEFINES INB1. 
O03 INB21 PIC X(4). 
03 INB22 PIC X(1996). 


2 In the PROCEDURE DIVISION code as follows : 


RECEIVE CDIN MESSAGE INTO INBUF. 
IF INB21="STOP'" GO TO TERM-PROG. 


The data representation cited is valid for any transmission code. 


The following problems, however, arise, 


The Level 64 internal code is EBCDIC while most of the terminals use the 
ISO ASCII code. The translation from EBCDIC to ASCII, and vice versa, is ex- 
ecuted by the TURP or URP according to the TCT tables loaded by BINS. 


A small number of special characters are rendered differently as follows, 


EBCDIC graphic : ! (e.ge, GCOS64) 


ISO graphic : ! (e.g-, VIP terminal) 


This means that when a user wants to display on, Say, a VIP terminal the 
text : 


VERSION DATED : [ 78/03/28 ] 


he must declare in the data division of his program the following : 


77 VERS PIC X(24) "VERSION DATED : ¢ 78/03/28 !" 
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EBCDIC representation is only used for local unit record devices, such as 
the system console, card reader/punch and line printer. 


« The character set(s) available on the devices used to create and enter the 
COBOL program depexds on the means of entry, 


-~ If the program is entered in the form of cards, the only character set pos- 
sible is that of the standard EBCDIC character set,.or a part of the set, 
allowed on the keypunche 
Furthermore, the Level 64 card reader does not recognize lower case let- 
ters, thus restricting even more the character set available for use. 


- If the program is created under IOF (interactive operation facility) from 
a terminal having upper and lover case capability, ieee, shift-in/shift- 
out, the character range defining the set is greatly extended. 

Lower case letters in literal strings are allowed by the COBOL compiler. 


A program on cards can only declare : 


77 DAT PIC X(5) VALUE "DATE:". 


A program created from a VIP7760 terminal can declare the format 
as above and, in addition, the following, 


77 DAT PIC X(5) VALUE ''date:". 


The listing of the program on the line printer will only display 
upper case letters, even in the second case. 


» Specific national language options have different graphic symbols. 
On sume terminals used in German-speaking countries, 


0 replaces \ 


If the programmer wants to send 0, he has to declare \in the data 
stringe 


For such special characters, the only way to ensure correct processing is to 
proceed as follows, 


- refer in the appropriate terminal manual the ASCII value of the character 
- find its EBCDIC equivalent, see "Translation from ASCII to EBCDIC" 


- find the Level 64 graphic equivalent, where applicable, see "EBCDIC Charac- 
tex Set and COBOL Collating Sequence". 


0 
Problem : To send the character A 


Solution : 


Proceed as follows : 


Refer to the terminal manual for t 


Oo 
Let us say that the ASCII value for A=24 


2 Refer to the table "Translation from ASCII to EBCDIC"! 


ASCII 24 = EBCDIC 5B 


3 Refer to the table "EBCDIC Character Set & COBOL Collating 
Sequence"! 


EBCDIC 5B = graphic symbol $ 


0 
Declare $ in the data division in order to display A 
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COBOL COLLATING SEQUENCE 


The facility allows the COBOL pregrammer to represent any character by using its 
value defined by its collating sequence known to the COBOL compiler. 


Problem : To send the text containing upper and lower case letters 


Solution : 


Proceed as follows : 


1 Refer to the table "EBCDIC Character Set & COBOL Collating Sequence"! 
for the COBOL collating sequence values of the characters required 


D=197 3; a=130 3; t=164 ; e=134 


2 Declare in the data division of the program either form of coding : 


77 DAT PIC X(16) VALUE "D''"'130, 164,134. 


77 DAT PIC X(20) VALUE ''''197, 130,164,134", 
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MARK REPRESENTATION 


Mark representation is a general facility of MCS to represent information data 
and control characters in an easy-to-use symbolic form using their EBCDIC values. 


The types of information data for the facility are, 


. character-encoding marks : 


oe | 
Problem : To send the text containing upper and lower case 
letters : 


Solution : 


Proceed as follows : 


1 Refer to the table "EBCDIC Character Set & COBOL Collating 
Sequence'! for the EBCDIC values of the characters required 


2 Declare in the data division of the program either form of 
coding 


77 DAT PIC X(16) VALUE "D><C81><CA3 ><C85"'. 


77 DAT PIC X(20) VALUE "><CC4><C81><CA3 ><C85". 


+ repeat marks ; 


Problem : To send a string of 80 asterisks * 


Solution ;: 


Proceed as follows : 


Declare in the data division of the program either form of coding 


77 AST PIC X(6) VALUE '><R80*". 


77 AST PIC X(10) VALUE "><R80><C5C"'. » *=EBCDIC 5C 


Control Character Representation 


Control functions generated by the terminal or encoded by the programmer to send 
to the terminal are represented as control characters. 


Control characters are generally restricted to the lower EBCDIC values; however, 
some terminal manufacturers use for specific control functions, 

» other EBCDIC values not reserved for the terminal in question 

- a combination of control characters and/or graphic symbols (escape sequences) 


For detailed information on the control functions for specific terminals, see 
Appendix Be 


VIP7700 Control Characters 


The following are examples of control functions specific to the VIP7700 : 


The "form feed" control character for clearing the screen and position- 
ing the cursor is the standard EBCDIC value OC. 


The "blink" function is activated by the EBCDIC value 5F. 


For other terminals, say the TN300, 5F represents the graphic symbol ~ 
(circumflex). 


The cassette read command is implemented by the following sequence of 2 


EBCDIC values, namely 


=]s|}—- Ee 


where EBCDIC 27 = ESC or "escape" control character 
and EBCDIC C5 = E, ieew, the graphic character 


NO VISIBILITY OF CONTROL CHARACTERS 


If the user is not concerned with control characters generated by the terminal 
and only wants to activate basic editing functions when sending messages, he 
should specify the normal mode for both input and output transmission. 


On input, all control characters will be suppressed from the message text by MCS. 


On output, the user may activate basic editing functions by specifying, 
« the ADVANCING clause of the COBOL SEND verb 
« the automatic editing functions provided by MCS thru the following parameters 
of the NDL TERMNL command, namely, 
- BLOCKING 
- LLENGTH 
~ NBLOCKS 
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- ADVANCING clause : 


The ADVANCING clause is used in the last SEND which terminates the message, 
ie@e, SEND WITH EMI or SEND WITH EGI. 


MCS then automatically generates control characters for insertion before 
and after the message text according to 

- the type of the device receiving the message 

- the control function requested. 


Problem : To perform the following on the VIP7700 terminal 
« to build the screen line by line 
» to generate a ''form feed" function on the last line of 
the message. 


Solution : 


Take the following considerations into account, 

« the VIP7700 automatically performs a "new line" function at the 
end of each line 

» to generate a "form feed'' function, specify AFTER ADVANCING PAGE 
in the last line of the message 


Proceed as follows : 


1 In the DATA DIVISION declare as follows : 


77 OUTBUF PIC X(80). 


77 IDX COMP-1. 


2 In the PROCEDURE DIVISION use either coding : 


MOVE O TO IDX. 
MOVE TEXT TO OUTBUF. 
* LOOP TO SEND 23 FIRST TEXT LINES 
LOOP23. 
SEND CDOUT FROM OUTBUF. 
ADD 1 TO IDX. 
IF IDX < 23 GO TO LOOP23. 
* SEND LAST LINE ADVANCING PAGE. 
SEND CDOUT FROM OUTBUF WITH EMI 
AFTER ADVANCING PAGE. 


MOVE O TO IDX. 
MOVE TEXT TO OUTBUF. 
* LOOP TO SEND 24 TEXT LINES 
LOOP24. 
SEND CDOUT FROM OUTBUF-. 
ADD 1 TO IDX. 
IF IDX < 24 GO TO LOOP24, 
* CLOSE MESSAGE AND SPECIFY ADVANCING. 
SEND CDOUT WITH EMI AFTER ADVANCING PAGE. 
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« automatic MCS editing : 


For the detailed description of the parameters providing automatic MCS 
editing, see TERMNL command in Section V. 


When this facility is activated, MCS inserts control characters in the 
message text to execute a ''new line" function, namely, 

- at the beginning of the message 

- after each string of characters defined by LLENGTH 


NBLOCKS specifies the number of lines, each line containing the number 

of characters defined by LLENGTH, to be accepted for each message. 

If a message is greater that NBLOCKS x LLENGTH, then the characters in ex- 
cess are discarded by MCS, 


MARK REPRESENTATION 


The transmission modes for which mark representation of control functions can 
be used are marked mode on input and normal mode on outpute 


e control character standard marks : 


For terminals recognized as standard to Level 64 by MCS, the symbolic 
representation of standard control characters is given in the tables 
"Gontrol Characters & EBCDIC Values" and "EBCDIC Values & Control Charac- 
ters". 


The control characters listed are dependent on, 
- the direction of transmission, iee., input or output 
- the type of line procedure used, ieee, TTY, VIP or BSG. 


The mark ><CAN is treated as follows, 


« for a TTY terminal 


- On being sent to or received from a TTY terminal, the mark 
represents the control function CANCEL, and the appropriate 
editing takes place in either direction 


e For a VIP terminal : 


~ On being received from a VIP terminal, the mark represents 
the control function CANCEL, and the appropriate editing 
takes place on inpute 


- On being sent to a VIP terminal, the mark does not represent 
a control function, and is, instead, treated as any other 
datae 


4-30 


» character-encoding marks : 


The facility is used to send 

- control characters not defined as standard marks 

- a control sequence of characters which individually are neither con- 
trol characters nor graphic characters. 


Problem : To position the cursor of the VIP7700 terminal at 
column 37 of line 11 


Solution : 


Proceed as follows : 


1 Refer to the VIP7700 terminal manual for the format of 
command to position the cursor 


command : DC3 3; parameters following command are 


» line number 
« character position 


2 Refer to the table overleaf, "ASCII Code for Control 
Characters & Graphic Symbols with EBCDIC Equivalents" 
for values of "line number" and "character position" 


In order to determine the EBCDIC value to be given 
line 11, proceed as follows, 


Start from ASCII code 20 which is a "space" 
Count 11 codes from the ASCII code 20 
The ASCII code arrived at is 2A or graphic * 
The EBCDIC equivalent is 5C 
In order to determine the EBCDIC value to be given 
character position 37, proceed as follows, 
Start from ASCII code 20 which is a "space" 
Count 37 codes from the ASCII code 20 
The ASCII code arrived at is 44 or graphic D 
The EBCDIC equivalent is C4 


3. In the COBOL program use one of the character strings 


><DC3*D 


><DC3><Cc5e><cc4 


4-31 


ASCII Code for Control Characters & Graphic Symbols 


ASCII 
function 


with EBCDIC Equivalents 


Explanation of text : 
"function'' includes 
« control characters 


e graphic symbols 
function 
EBCDIC optional graphic symbols 
appear on ieft wh 2 
ASCII Su pga las 


5B Symbols are given. 
6C function 


50 EBCDIC 


7D , Ch ASCII 
C5 function 
EBCDIC 


re C6 
C7 ASCII 
function 


5C 79 
= oH [cs oT EBCDIC 
le 82 
hs wy |p1 83 Bos AT 
D2 79 A8 
7A AQ 
D3 mie co 
FO 87 
on [D5 7C 6A 


“0 |D6 7D DO 
= od ba Al 


De YP ID7 7 7F | DEL| 07 
ae 91 

F4 oe -\pe 92 

F5 : 


F6 oe TBs 93 


F7 m 94 
Sl es 95 


F8 ay | ES 96 
sy [BS 

F9 Slee 

7A 97 

5E eles 98 
Poles 99 

AC ole AQ 

JE } 


6E bes A3 


6F | Ad 
AS 

1¢ : A6 

Cl 

C2 

C3 


4B } 84 
61 - 85 
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« VIP header marks : 


For the VIP line procedure, control characters are embedded in the user 
message text by BINS which automatically provides headers and trailers. 


The three parameters in the VIP header, which are of use, are, 

- STA, the status of the terminal 

- FC1, function-code-1 

- FC2, function-code-2. 

For a detailed description of these control functions, refer to the 
VIP7700 terminal manual and Appendix B. 


The only way to access these control characters both in input and output 
mode from a COBOL program is the VIP header mark of the form ><UO3abc 
which is: 

- delivered on input in front of the message text by the terminal 

- provided on output in front of the message text by the user 

- allowed in the unedited mode of transmission. 


COBOL COLLATING SEQUENCE 


The facility is available to the programmer who wishes to manipulate control 
characters directly. In order to do this, the terminals must be set in the un- 
edited mode of transmission. 


The EBCDIC values of the control characters must be declared thru their equiva- 
lent values of the COBOL collating sequence, as defined in the table "EBCDIC 
Character Set & COBOL Collating Sequence’. 


Problem : To send to the printer of the VIP7700 two consecutive lines of 
the following text BOOKINGS followed by NUMBERS: 


Solution : 


Proceed as follows : 


1 To address the VIP7700 printer use the following values, 


STA = EBCDIC 3F = COBOL collating sequence value 64 


FC1 and FC2, to be left initially as spaces 


2 To position hard copy for second line of text, use the values, 


CRV = EBCDIC OD = COBOL collating sequence value 14 
LFV = EBCDIC 25 = COBOL collating sequence value 38 


3 Declare in the data division 


77 HEAD PIC X(35) VALUE ">< U03"64"VVBOOKINGS''14'''38'"'NUMBERS: '"'. 
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SECTION V 


CNC is a system utility program used to generate the communications environment 
to provide the network and software support for the correct execution of, 

- BINS, basic terminal network support 

- MAM, message access method 

« VCAM, virtual communications access method 

« QMAINT, queue maintenance 

- MCS COBOL application programs 


CNC is described in terms of: 
- Input Data 
- Output Data 
- Command Language 
- Executing CNC 
« Tuning the Network 


INPUT DATA 


The input data to CNC is in the form of, 
» NDL commands, network description language 
- Site SRST, system resource and status table 
« Preallocated Disk Queue Files 


NDL Commands 


The NDL commands to CNC are introduced either on cards forming an input enclo- 
sure in a deck of JCL statements, or as a subfile retrieved from a source libra- 
Lye 

If the NDL commands are to be used repeatedly for setting up the same communica- 
tions environment, then they should be stored as a member of a library. 


Site SRST 


The SRST contains the hardware description and status of each communications 
line available to the site. 
CNC checks the hardware availability of the lines declared thru NDL commands and 
parameters which are of importance to BTNS, such as, 

» Line procedure 

« Line type, ieee, leased, local or switched 

« Allowed line speeds for a particular DCC (data communications controller). 


Preallocated Disk Queue Files 


Tf disk queues are to be generated, then the disk queue file must first be pre- 
allocated, see Section III 'Preallocating a Disk Queue File". 


The volume containing the disk queue file must be mounted, and the file must be 
ASSIGNed to the H_CNC step. 

The disk queue file is then preformatted based on queue specifications 
in the network description. 


OUTPUT DATA 


The output data from CNC is in the form of, 
« Communications System Tables 
« Gopy of Tables in a System File 
« Preformatted Queue Files 
- Output Reports 


Communications System Tables 


On successful completion of the H_CNC step, a set of communications system 
tables is created. 
The contents of these tables incorporate the complete network description 
derived from the analysis of the specifications contained in the NDL commands, 
principally, 

- Relating terminals to stations to lines 

- Classifying component names with the appropriate component addresses 

- Aligning queues with sources or destinations 

« Computing buffer sizes per line. 


The communications system tables are used by BINS, MAM and VCAM to control the 
network for running user applications. 


Copy of Tables in a System File 


The set of communications system tables is copied in an area in backing store. 
A new version of these tables is created with each execution of the H_CNC step. 


The file is used as follows, 


- At system initialization : to restore the tables into reserved system seg- 
ments, without having to regenerate the network 
using the CNC utility. 

A new generation is not required for the current 
network except in cases of modification. 


« At BINS startup to restore the tables which may have been altered 
by operator commands during a previous communi- 
cations session. 

BINS is started up by the ST network control com- 
mand which can be entered on the system console 
or on the network control terminal, see Appendix 


F. 


Preformatted Queue Files 


The preallocated disk queue file is preformatted on successful termination of 
the H_CNC step. 

Control records are written at the beginning of the file for the purpose of re- 
Starting disk queues. The actual format of the control records is based on queue 
specifications from the network description 


Memory queues defined in the network description are preformatted in main memory. 
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Output Reports 


Print-out reports can be of the following, 


SYSOUT Report : The information contained in the report 
- Lists the NDL commands used 
- Summarizes the makeup of the network environment generated 
- Indicates any errors detected during the execution of 
H_CNC utility. 


For list of NDL error messages, see Appendix CG. 


JOR Messages : When system errors occur, 
- The step is invariably aborted 
- Messages are written to the JOR (job occurrence report). 


For list of JOR error messages, see Appendix C. 


COMMAND LANGUAGE 


NDL commands are described in terms of, 


Language Convention 
Command Repertoire 


Language Convention 


Commands and their parameters are written in capitals. 


The following symbols must not be employed in user-supplied values, 


» comma / slash ( open parenthesis 


V blank = equals ) close parenthesis 


3 semi-colon * asterisk " quotation mark 


Language reserved names must not be employed in user-supplied values. 
For summary of NDL commands and reserved syntax, see Appendix E. 


A command can span several cards, the end of the command being terminated 
by a semi-colon. 


Individual parameters of a command can be separated by commas, blanks or 
commas and blanks. 


Blank cards and ''comment'' cards are not processed. 


Default values are underlined; if no default is specified, a value must be 
supplied. 


A user-supplied value that lies beyond the range of permitted values is dis- 
allowed. 


Command Repertoire 


There are 7 commands, namely, 


COMM 
DCTAP 
GENCOM 
LINE 
QUEUE 
STATN 
TERMNL 


defines a ''comment" 

identifies the version cf the VCAM subsystem 

describes the environment in which the network is to function 
defines the characteristics of the communications line 
defines all the queues to be used by the network 

defines a station attached to a polled line 


defines the characteristics of the terminal 


commands are listed with the following information, 


Definition 


Format of Command 
Parameter Descriptions 


Examples 
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COMM 


Definition 
The COMM command defines a comment and may appear anywhere in the description 
after the GENCOM command and even within the LINE-STATN-TERMNL sequence. 


Format of Command 
COMM "string" 


Parameter Descriptions 


"string" 
- a character string between quotation marks that must be opened and closed 


on the same card. 
A maximum of 72 characters can be specified for each COMM command If a 


comment is greater than 72 characters, then the excess number of characters 
must appear on a following COMM command. . 


DCTAP 


Definition 


The DCTAP command identifies a version of the VCAM subsystem that uses the 
network being described. 


Format of Command 


DCTAP name P sun} * a 


Parameter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and defines, 
» the name given to a particular version of TDS at TDS generation, 


see TDS/64 Programmer Reference Manual 
» the Interactive Operation Facility subsystem, in which case the name is 
IOF 


SIMU 
- an integer whose range depends on the version of the VCAM subsystem, namely, 
- IOF : from 1 thru 10, being the number of terminals defined by the 
INTERACT clause at system generation (SYSGEN). 


- TDS : from 1 thru 5, being the number of simultaneities defined by the 
SIMULTANEITY clause at TDS generation. 


The default value is 1. 


Examp les 


1) DCTAP TDS1; 
This command identifies a generation of TDS named TDS1 generated with 1 
level of simultaneity. 


2) DCTAP IOF,SIMU=5; 
This command specifies that 5 interactive terminals may be connected 
simultaneously to the ICSF subsystem 


GENCOM 


Definition 
The GENCOM command defines the start of network generation and precedes all 
other commands. In addition to naming the network, this command describes the 
environment in which the network is to function. 


Format of Command 


GENCOM name | sarcno-t! Alt presz=) 4] 
n nnn 


skEvpassvora| » MAMNB= * | 


| qosixs2=}70 | [ acrooL | [ QDBLKSZ= 
nnnn nnnn 


ait Sesto | 


asrsa-} | 
nnnn 


» NBBTBF=nnn ys20a8e—nnn| 


70 
nnnn 


TN 
ce Wf 


{oO 


NN XX 


[ SIMBRK= 


Parameter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and uniquely identifies the 


site name for the local network description. 

If the 'name" is less than 4 characters, the system will fill in the rest of 
the "name" with "underscore" graphic symbols when identifying the network. 
Multiple descriptions may be cataloged as members of a source library, see 
Section IV. 


BAT CHNB 
- VCAM oriented parameter which specifies the maximum number of batch entry 
utility processes that can be connected simultaneously to TDS. 
For a detailed description, see TDS/64 Site Manual and TDS/64 Programmer 
Reference Manual. 
The default value is 1. 


BI BFSZ 
- specifies the size in bytes of each unit forming the buffer pool used by 
BTNS during I/O transfers over the lines. 
The buffer pool services terminals sending to and receiving from queues 
and, where applicable, those terminals sending to VCAM subsystems. 
Buffer unit size ranges from 112 thru 512 in multiples of 16. 
The default value is 144. . . 
If the value specified is not in multiples of 16, then the size is rounded 
up to the nearest multiple. 


DABFSZ 
- VCAM oriented parameter which specifies the size in bytes of each unit 

forming the VCAM buffer pool used by BINS for the sole purpose of sending 
messages to terminals connected to VCAM subsystems. 
The buffer pool is required by BTNS only if VCAM subsystems are declared, 
such as IOF and TDS in a DCTAP command. 
Buffer unit size ranges from 112 thru 1024 in multiples of 16. 
The default value is 144. 
If the value specified is not in multiples of 16, then the size is rounded 
up to the nearest multiple. 
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GENCOM 
continued 


KEY 
- MCS oriented parameter which defines the unique password used by MCS COBOL 
application programs to execute ENABLE and DISABLE verbs as specified thru 
the KEY parameter of the verbs. 
If the parameter is not specified, no checking is done by MAM when the 
& verbs are executed. 
{| The password ranges from 1 thru 10 alphanumeric characters. 


MAMNB 
(om oriented parameter which specifies the maximum number of MCS COBOL 
application processes that can be executing concurrently. 
For the multi-process application, each constituent process 
is to be individually counted. 
The default value is 1. 


NBBTBF 
- specifies the number of units of the buffer pool used by BINS during I/0 


transfers over the lines. 

The buffer pool services terminals sending to and receiving from queues 
and, where applicable, those terminals sending to VCAM subsystems. 

The minimum number is 8. 

The number of units is defined by the algorithn, 


(NBBTBF x BTBFSZ) < 65504 


For default value, see "Tuning the Network" later in the section. 


NBDABF 
- VCAM oriented parameter which specifies the number of units of the VCAM 


buffer pool used by BINS for the sole purpose of sending messages to 
terminals connected to VCAM subsystems. 

The buffer pool is required by BTNS only if VCAM subsystems are declared, 
such as IOF and TDS in a DCTAP command. 

The minimum number is &. 

The number of units is defined by the algorithm, 


(NBDABF X DABFSZ) < 65504 


For default value, see "'Tuning the Netwerk" later in the section. 


QCBLKSZ 
- S oriented parameter which specifies the size in bytes of each core block 


used to generate the core queue pool. 
Core block size ranges from 70 thru 1024. 
The default value is 70. 


= S oriented parameter which specifies the number of core blocks of the 
core queue pool to be shared by all queues qualified by the QCPOOL option 
in their respective QUEUE commands. 
The number of core blocks is defined by the algorithn, 


(QCPOOL + NUMBLK) xX QCBLKSZ < 65535 


For NUMBLK, see QUEUE command. 
The default value is 0. 


GENCOM 
continued 


QDBLKSZ 


- MCS oriented parameter which specifies the block size in bytes of the disk 


queue file used for saving messages. 
The block size Specified is the size of the MAM buffer unit used to store 


messages before being written to the file. 


The disk block size ranges from 70 thru 1024. 
The default value is 70. 


= 
( SIMBR 


y 
“) 


= 


= ranges from 1 thru 3 alphanumeric characters enclosed within quotation 


marks. 

The character string serves as a break qualifier to precede the terminal 
operator command for identification by BINS as a network control command. 
For terminal operations, see Communications Network Control Terminal 


Operations Manual and Terminal Operations GCOS Manual. 
The default value is $*$. 


SYSLOG 
Gis10) all system messages sent by BINS (site controller) to the network 


control terminal or any other terminal of the network are to be logged in 
order to be printed out at the end of the BTNS session, together with the 
job occurrence report of BTNS. 
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GENCOM 
continued 


Examples 


1) GENCOM MCS1, BTBFSZ=200, KEY=PASS , MAMNB=2, NBBT BF=20, QCBLKSZ=205 , QCPOOL=50; 
This command names a network MCS1 which specifies: 
- BIBFSZ=200,NBBTBF=20 
The BINS buffer pool is made up of 20 units of 200 bytes per unit. 
- KEY=PASS 
The ENABLE and DISABLE verbs issued by MCS COBOL application programs 
will have to specify the KEY parameter. 
- MAMNB=2 
Concurrent execution of either 
- 2 single process (monoprocess) applications 
- 1 MCS application having 2 constituent processes or subprocesses, 
ieee, 1 dual process application. 
NBBTBF, see BTBFSZ 
. - QCBLKSZ=205 
Ny Core block size is 205 bytes partitioned as follows, 
y - © bytes reserved for MAM control information 
- 200 bytes for storing message text. 
- QCPOOL=50 
A set of 50 core blocks is reserved in the core queue pool. 


2) GENCOM DAC1, BATCHNB=3, BTBFSZ=150, DABFSZ=150, NBDABF=30, SIMBRK=""7%""5 
This command names a network DAC1 which specifies: 
- BATCHNB=3 
3 batch entry utility processes can be simultaneously connected. 
~ BIBFSZ=150 
-The size of the BINS buffer unit is 150 bytes. 
The number of buffer units is automatically determined by CNC according 
to the network components. 
- DABFSZ=150, NBDABF=30 
The VCAM buffer pool is made up of 30 units of 150 bytes per unit. 
- NBDABF, see above 
- SIMBRK="'%"' 
The break qualifier for network control commands is % 


LINE 


Definition 


The LINE cemmand identifies the line and defines its characteristics. Each 
cemmunicatien line te be supperted by the network declared must be described 
by a Separate LINE command. 


LINE LNnn [, 8kMoD][, CcINS=nnn][, cLOSE][, cLV=n][, EPX ][, ERCAP] 
[, ININS=nnn][, LINPLG ][, NAUCDE ][, PADNB=nn }[, PARITY=n] 


[,vottast=(onf, on)... 9] 2Rraa=}py{/enon/) SE TP excxrnn 


7 No ASCII m 
t sPEED=x| : SPN } ; |, ssr| . rome} sscrt| |f rrzen-onn] 


[, TOLEN=nnn J; 


TLT Parameters 


The TLT is a URP table attached to each line which contains all the parameters 
characterizing the functionality of the line. Some of these parameters not 
accessible to system software must be initialized during URP image generation 
using the LPGEN utility program Other parameters are initialized by BINS for 
each line during the start-up phase except for those lines declared CLCSEd, 

in which case an RT network control command must be issued for processing of 
the line to be activated. 

The TLT loaded by BINS is built up by CNC which reads hardware parameters from 
the URP and initializes system software visible parameters either with default 
values or with parameters explicitly specified in the NDL commands. 

The default values of each parameter are summarized at the end of this command 
description. 


The parameters may be classified into 3 categories: 

» TLT Tuning Parameters which can be dynamically modified during the BTNS 
session by means of the MIL network control command. 

- TLT System Parameters which depend on the requirements of the application 
program and are determined by the systems analyst/programmer or which are 
affected by manipulative procedures under the control of the terminal 
operator. 

- TLT Hardware and Procedure Parameters which depend mainly on the hardware 
characteristics of terminals, modems and procedure specifics. 


Parameter Descriptions 


LNnn 
- uniquely defines the line within the network and is declared in the SRST 
at the time of installation. 
Values range from O01 thru 99 
CNC checks that the line declared is 
» present in the SRST 
- connected and available 
» not the system console (usually allocated LNO1 or CSP in the SRST) 


LINE 
continued 


(pxmop) 
-“TLT system parameter which specifies the effect of a "break" during the 


output of a message. The parameter is applicable only for TTY terminals 
equipped with the BREAK key. 


- If specified, output is irmediately terminated. 
- If not specified, then output continues until the end cf the current 
message before the "break" condition is reported to BTNS. 


CCINS 


TLT hardware/procedure parameter defining the number of "fill" characters 
to be inserted after the control character activating i mechanical 
function, such as "carriage return" or "line feed", in order to avoid 
losing the following data characters that would be transmitted during the 
execution of that function. 

The number of "fili'" characters ranges from O thru 127 and depends on the 


nN terminal type. 
c If 0 is specified, no "fill" characters are inserted. 
LOSE 
=“Specifies that BINS must not initialize traffic over the line declared 
until an RT network control command is issued in order to start processing 
of the line. 
TLT for the line is not even loaded during BINS start-up. 
By default a line is active. 
CLV 
- TLT hardware/procedure parameter which specifies the code level used on the 
line (including the parity bit, where applicable). 
Values range from O thru 3 with the following meanings, 
O : 8 bit code 
Li 7 bit) code 
2: 6 bit code 
3 5 bit code 
The 5 bit code is illegal for a synchronous line, ise. VIP Synchronous or 
BSC. 
EPX 


TLT system parameter which specifies that echoplex is used over a TTY line. 
A character received by the URP is turned around to the transmitting 
terminal. 

Echoplex can only be specified for fully duplex lines and can be used for 
TTY37 type terminals having a printer and keyboard disconnectable from 
each other. 


ae system parameter which specifies the "erase" capability for TTY lines. 


When specified, the operator may delete the last character by keying in a 
"back slash" or "reverse slant" character (\). 

The input message length which includes "erase"! ch@racters must not be 
greater than (BTBFSZ - 9). 

For BTBFSZ, see GENCOM command. 


LINE 
continued 


ININS 
- TLT hardware/procedure parameter which defines the number of SYN characters 


to be sent before each message to allow for synchronization. 

The parameter is only applicable for a synchronous line, ite. VIP 
Synchronous or BSG. 

The number of SYN characters range from O thru 127 and depends on the 
characteristics and quality of the terminal. 

Tf O is specified, 2 SYN characters are inserted. 


LINPLG 
- TLT system parameter which specifies that polling for a multipoint line 


must be linear, ieee polling to start at the top of the list. © 
By defauit, round-robin polling is assumed, ise. subsequent polling starts 
after the last entry successfully polled. 


NAUCDE 
- TLT hardware/procedure parameter only applicable for a switched line. 
Inhibits the detection of the ring indicator over the line, thus making it 
unavailable to the network. 
In order for the line to be made available, the parameter must be omitted in 
the next network generation. 


PADNB 
- TLT hardware/procedure parameter which defines the number of PAD characters 
to be sent at the end of the output message in order to avoid losing the 
last character(s) in case of turn-around on reception 
The number of PAD characters ranges from to 15 and depends on modem 
characteristics. 


PARITY 
- TLT hardware/procedure parameter used tc check the parity on input and 
depends on the type of terminal connected. 
Values range from O thru 3 with the following meanings, 


Q : Code without parity 

1 : Code with "pseudo-parity", iee., the parity bit is always set to l 
2 : Code with even parity ieee, the number of '"'1-bits'’ is even 

3: Code with odd parity, iee., the number of '"'l-bits' is odd 


POLLIST 
- specifies the polling list to be used over the line which must be declared 
multipoint in the SRST, iee., VIP. 


The stations to be polled are identified by their STIs, station indexes, 
which range in value from 1 thru 32. 

The number of stations entered on the list must not be greater than the 
number defined for the SRST parameter POLISTLENGTH declared for the line. 
STIs may be repeated in any order provided, they correspond with the STIs 
declared by STATN commands following this LINE command. 

The polling list may be modified by the MTP network control command provided 
that the number of stations in the new polling list does not exceed that 
originally specified. 

The default polling list for the line is established by the order in which 
successive STATN commands are specified for the line, ieee, 1 entry per 
Station in the polling list. 


LINE 
continued 


PRIRA 


MCS criented parameter specifying input or output priority on a line. 
The number of priority actions to be attempted before taking the other 
action ranges from 1 thru 4096. 

The default is 1 input action for every output action. 


{ grro |QuIn} 

specifies the order in which terminals connected to MCS COBOL applications 
using output queues are scanned. 

If QLIN is specified, the scan begins with the first output queue declared 
and keeps on returning to this queue until all data is output before the 
next queue is scanned. 

The default is QRRO in which the scan begins with the first output queue 
declared and then resumes at the next queue, irrespective of whether all 
data in the previous queue has been output. 


RT CNT 


TLT hardware/procedure parameter which specifies the number of retries to 
be attempted when an error occurs in transmission. 
Values range from 1 thru 99% 


SPEED 


SPN 


TLT tuning parameter which defines the speed of an asynchronous line, iee, 
TY or VIP asynchronous. 

Values range from A thru O representing the following speeds in bits per 
second. 


A= 50 F = 150 K = 1050 
B= 75 G = 200 L = 1200 
Cc = 100 Ho = 3006 M = 1800 
D = 110 I = 600 N = 2000 
E = 135 J = 900 O = 2400 


A Data Communications Controller (DCC) is configured with 4 of the 15 
speeds listed. CNC checks that the value defined for the parameter is 1 cf 
the 4 speeds configured on the DCC which connects the line. 

The speed of a line is selected from the 4 values and is specified at SRST 
generation time, by the LINE resource card, in order to tailor the URP 
buffers for that line. 

In order to override the SRST value, the SPEED parameter supplies the new 
value which must be compatible with generated URP buffers for that line 


TLT hardware/procedure parameter which defines the number of stop bits to 
be sent after each character in asynchronous transmission, ieee, TTY, 

or VIP asynchronous. 

Values can be either O or 1 depending on terminal type and have the 
following meanings. 


O: 1 stop bit 
1: 2 stop bits 


LINE 


continued 
SSR 
- TLT hardware/procedure parameter which is specified according to the type 
of modem and line speed, as given in the table below. 
Modem Characteristics Pa 
Position 
Selection Mode | Interface | of Modem 
300] asynchronous] frequency emission|Pin 11 aaa | 
600] asynchronous debit binary i 
asynchronous debit binary 
synchronous debit binary 
synchronous debit binary 
-any- -any- 
TCTNM 
- }ascr1|sprty} 
TLT hardware/procedure parameter which allows selecting a translation 
table other than the standard one defined for the line procedure. 
ASCII is specified for some BSC transmissions, depending on the terminal 
type, and defines an ASCII-to-ASCII translation table. 
SPTTY defines the standard TTY translation table and may be patched to 
obtain specific functions, eeg., alteration of "erase" or "end-of-message" 
characters. 
TILEN 


- TLT tuning parameter which defines the "time-out'! value used by the URP to 
control initialization or disconnection of the modem 
The "time-out"' value ranges from 20 thru 255 units, each unit being 50 
milliseconds. 
In the diagram below, the value specified must be greater than either t1 or 
t2, both values depending on the quality of the modem 
If the "time-out" value is too small, BINS will display the message on 
initialization: "CC21 LNnn CANNOT BE OPENED REASON: ENABLE CP FAILED" 3 on 
disconnection : "CC11 LNnn HELD BY SYSTEM REASON: DISABLE ERROR". 
The parameter can be modified by the MTL network control command of the for- 
mat "MTL LNnn input-timeout". 


DTR —_ : 
Initialization eee ie ee 
DSR : ; 
DIR —j 
Disconnection ET ee ee ee a ea 
DSR OE ee eee 
ie t 2 — a! 


LINE 
continued 


TOLEN 
- TLT tuning parameter which defines the "time-out" value used by the URP, 


- when polling a buffered terminal 
- when timing the interval between characters input from an unbuffered 
terminal. — 
Buffered terminals: 
The ''time-out'' value ranges from O thru 65535 units, each unit being 50 
milliseconds. 
O value gives a "time-out" value of 50 x 65536 milliseconds. 
Unbuffered terminals: 
The "time-out'' value ranges from O thru 255 units, each unit being 2 
seconds. 
O value gives a "time-out" value of 2 x 256 seconds. 
If "time-out" occurs when polling a buffered terminal, BINS reports the 
condition on the network console: '"'CC13 station-name UNAVAILABLE". 
If "time-out" occurs for an unbuffered terminal, BTNS will deliver the 
text already input to the application program, and then launch a new "read", 
If "time-out'' occurs for a switched line, BTNS disconnects the line. 
The parameter can be modified by the MTL network control command of the for- 
mat "MTL LNnn cutput-timeout". 


TLT Parameter Default Values 


Line Transmission Procedure 


PLY VIP VIP BSC 
Parameter 
Asynchronous] Synchronous 


CCINS 3 (DLE) O (DLE) 6 (DLE) 2 (SYN) 
CLV 6) 0 


ININS 
PADNB 
PARITY 
RTCNT 
SPEED 


SPN 
TCTNM 
TILEN (b) 
TOLEN (c) 


Note : (a) values defined by SRST entry for the line 
(b) value of unit = 50 milliseconds 
(c) value of unit = 2 seconds for TTY, 50 milliseconds for others 
na = not applicable 


The table above only deals with parameters for which values are tc be defined. 
The default for options specified unly by the keyword is the absence cf the 
keyword. 
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LINE 
continued 


Allowed Options for LINE Parameters 


Line Transmission Procedure 


| 
TLY VIP VIP BSC 
Parameter 
Asynchronous | Synchronous 
yes no no no 


BKMOD 
CCINS yes yes 
CLOSE 
CLV 
EPX 
ERCAP 
ININS 
LINPLG 
NAUCDE (d) 
| PADNB 
PARITY 
POLLIST(e) 
PRIRA (f£) 
RTCNT 
SPEED 
SPN 
SSR 
TCTNM 
TILEN 
TOLEN 


Note : (d) allowed only if the line is declared switched in the SRST 
(e) allowed only if the line is declared multipoint in the SRST 
(f£) cnly if the terminals connected over the line are io be used by 
MCS COBOL applications 


LINE 
continued 


Examples 


1) LINE LN10; 
This command defines the line named LN10 in the SRST and which is to 
function with the default options defined by CNC according to the line 
procedure specified in the SRST. 


2) LINE LNO4, LINPLG, POLLIST=(1,1,1,2,3),TOLEN=4; 
This command defines a multipoint line named LNO4 which specifies: 
- LINPLG 
Each polling cycle is to start with the station identified by its STI=1 
at the "head" of the polling list defined by POLLIST. 
- POLLIST 
The variables specified for the parameter mean that 
« The length of the allowed polling list declared for the line LNO4 is 
at least 5, which accounts for the 5 STIs defined 
- For each polling cycle, the station identified by its STI=1 will be 
polled 3 times for every 1 successive time that stations 2 and 3 are 
polled. 
- TOLEN 
The "time-out" value used by URP firmware is 4 x 50 = 200 milliseconds. 
"Time-out'"' defines the lapse between sending the polling message and the 
station response. 


3) LINE LN15, CLOSE, EPX, ERCAP , SPEED=D; 

This command defines a line named LN15 which specifies: 

- CLOSE 
The line will not be initialized at BINS start-up but only thru an 
"RT LN15'"' network control command. 

- EPX 
The line declared is a TTY line for which "echoplex" is to be used. 
The option is valid if the keyboard of the terminal is disconnected 
from the printer. 

- ERCAP 
The (\) character is to be used as the "erase'! character. 

- SPEED 
The line declared is a TTY line operating at a nominal speed, Say, 
300 bits per second (value = H). 
The speed of transmission is to be altered to 110 bits per second, ise, 
value =D, which is 1 of the 4 speeds configured for the line. 
Speed can be modified at run-time by the MTL network control command. 


QUEUE 


Definition 
The QUEUE command defines every physical queue, program and terminal queues, 
used by the network. The command gives the queue its external name and defines 
all its attributes. 
QUEUE commands can appear anywhere in the network description after the GENCOM 
command except between the LINE command and its asscciated STATN and/or TERMNL 
commands. 


Format of Command 


NUMBLK = nnn 
QUEUE name |,BREAK]|,CLOSE]], Teer ») NSUMREC = nnnnn 
RESTART 7 
QCPOOL 


son] 


Note : If neither NUMBLK, NUMREC nor QCPOOL are specified, then the queue is 
a disk queue of 32767 blocks. 


Paraneter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and uniquely cefines the queue 
within the network. 
, If the queue is a terminal queue, this external name must be identical with 
wl the name given to the terminal, see TERMNL command. 


BREAK 
- applicable only to program queues on which the MCS COBOL application will 
be netifiea of status concerning, 
- asynchronous events such as BREAK and RVI 
- terminal status changes such as connection and disconnection. 
For a detailed description of notifications and application program 
interface, see Section III. 


CLOSE 
-‘specifies that the queue is initially disabled, in which case, the first 
application to use the queue must first enable it, ieee, using the ENABLE 
verb, in order to allow data transfer between the queue and its asscciated 
terminal. 
onpXer 
- applicable only to terminal disk queues enabling controlled restart from b£C 
"step abort'! cr "system crash" using the recovery protocol defined in 
\. Section III. 
Ws, 
“NUMBLK) 
=—number cf memory blocks for the exclusive use of the declared queues 
The size of the core block in bytes is defined by the QCBLKSZ parameter in 
the GENCOM command. 
The usable size of the core block is (QCBLKSZ - 5). 
The number cf core blocks is defined by the algorithm, 


(SNUMBLK + QCPOOL) x QCBLKSZ < 65535 madden 
For QCPOOL, see GENCOM command. 


QUEUE 
continued 


NUPMREC 
~ number of blocks in the disk queue file for the exclusive use of the 
declared queue. 
For block size, see QDBLKSZ parameter in the GENCOM command. 
The usable size of the disk block is (QDBLKSZ - 5). 
The number of blocks is defined by the algorithm, 


ZNUMREC £32767 » see "Tuning the Network" later in the section 


QCPOOL 

(Goat) the queue as a memory queue which is to share the core queue pool 
reserved by the QCPOOL parameter in the GENCOM command. 
All queues qualified by the QCPOOL option in their respective QUEUE 
commands share the same common core pool. 
The option enables a saving of memory especially in the case cf interactive 
applications where traffic is not heavy enough to fill all queues at the 
same time, in which case, the same memory space can be used for at least 
more than 1 queue. 
The user must be careful since there is no protection for queues sharing 
the common core pool against an application exhausting the pool by its 
large output and thereby blocking other queues. Such an application should 
use a mix of pooled queues and queues defined by the NUMBLK parameter. 
For selecting the type and size of queues, see "Tuning the Network" later 
in the section. 


RESTART 
- applies only to disk queues, iee., program queues and terminal queues, 
enabling recovery from."Step abort'' or "system crash" by queue "roll back". 


S E 
- applies only to program queues thereby allowing 2 or more MCS COBOL 
applications to share the same queue defined either with input or input and 
output capability by their QASSIGN JCL statement. 
The option is useful in establishing interjob communication and must not be 
ay used if the program queue iS to be ASSIGNed as a subqueue, see $QASSIGN in 
= Section III. 


i ee only to program queues thereby enabling dialog wetween the 
application and the terminal according to the following procedure when 
either has the right of transmitting. 

The application: 
» Either 1 or more SEND WITH EMI can be executed whereby the application 
retains the right of transmitting 
- Or a SEND WITH EGI is executed whereby the application gives up its 
right of transmitting and transfers it to the terminal. 
The terminal: 
Even when the terminal has the right of transmitting, the application 
is master and can override this right. 
At the end of the message transmitted by the terminal, the right of 
transmitting passes to the application. 
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QUEUE 
continued 


Examples 


1) QUEUE DSK1, BREAK, RESTART, TWA; 
This command declares a disk queue named DSK1 which allows: 


- BREAK 


The application is notified of every asynchronous event coming from 
terminals associated with the queue. 

- RESTART 
"Roli bach" for recovery and restart is enabled even in the case of 
BINS abort. 

- TWA 
Dielog between the application and the terminals to which it is 
connected is enabled. 


2) QUEUE TER1, QCPOOL; 
This command declares a terminal core queue TER1 which is to share the core 
queue pool reserved by the GENCOM command with other queues qualified by 
the QCPCOL option in their respective QUEUE commands. 


STATN 


Definition 


The STATN command defines a station attached to a polled line and must be 
immediately followed by TERMNL commands defining the terminals composing the 
Station, before the next station on the line can be defined. 


The STATN command is required in every case except for the TTY line procedure. 


Format of Command 
STATN name, Station-index [ .cuose |; 


Parameter Descriptions 
name 


- ranges from 1 thru 4 alphanumeric characters and uniquely defines the 
station in the network. 


station-index 


- an integer ranging from 1 thru 32 defining the STI by which the station is 
polled 


The STI is the hardware address of the station configured in the SRST and 
is unique for each station on a given line. 


CLOSE 


- specifies that BTNS must not poll the station until an RT network control 
command is issued in order to start dialog with the station. 


Examples 
1) STATN STA1,4; 


This command defines a station named STA1 with an STI of 4 which has been 


previously specified in the POLLIST parameter of the associated LINE 
command. 


2) STATN STA2,1, CLOSE; 


This command defines a station named STA2 with an STI of 1 which will not be 
polled until an "RT STA2" network control command has been issued. 
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TERMNL 


Definition 
The TERMNL command defines the terminal as a uniquely addressable unit in the 
network and specifies the characteristics with which it is to function 
Except for the TTY line procedure, TERMNL commands defining the terminals 
composing the station must follow immediately the associated STATN command. 
For the TTY line procedure, for which the STATN command is not applicabie, the 
TERMNL command must follow immediately the associated LINE command. 


Format of Command 


terminal-type 


TERMNL name, TYPE= SLAVE 


» oTYPE=subtype [ ,apo=nn| 


[,uavero-on9]ftzencr-nona)fsstocKs-nnnn]| om | 


80 Nop25" ; 
[saxso=}80,{][ srsneanm rE | 


Parameter Descriptions 
- ranges from 1 thru 4 alphanumeric characters and uniquely defines the 


name 
terminal in the network. 
The reserved terminal name OPER defines the network control terminal 
having the following characteristics, 
« not connected over a switched line 
- of a "'terminal-type' other than 


- HL62 
- HL64 
- HL66 
- of a "subtype" restricted to 
- KCT, keyboard with screen 
. - KPR, keyboard with printer 
~ . not declared as a member of a LINE or STATN specified with the CLOSE 
* option 
at The network control terminal may be connected to an application. 
X The system conscle is the network control terminal by default, ieee, if 
no terminal has been so designated. 


TYPE 
<defines the type of standard terminal specific to the line procedure used. 
The terminal specified functions as a master terminal; where the terminal 
is to function as a slave, the parameter SLAVE is defined. 
See Section II '"Log-on Procedures" for further details. 
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TERMNL 
continued 


TYPE (continued) 


Types of Standard Terminals 


TTY VIP VIP BSC 
Asynchronous| Synchronous 


TN300 
TN1200 


TTU8124* 
TTU8 126% 


TTY33 


VIP765 


TTU8221% 


VIP775 


TTY35 

TTY37 VIP785 
TTY38 VIP77G0 
VIP7100 


VIP7200 VIP7760 


STYPE 
- specifies the characteristics with which the terminal described is to 


function such as, 

» its ability to receive system messages 

- its I/O capability 

- its default address. 

The possible choices of terminal subtype defining such characteristics are, 
e CAS Cassette 

« CPU Central Processor 

« CRT Screen 


~\e KB Keyboard 


Keyboard with Screen 
- KPR Keyboard with Printer 
» PRT Printer 
The I/O capability of the terminal is overridden by the declaration of its 
subtype, iee., if a keyboard printer terminal is declared PRT, then its 
keyboard will not be accessible to BTNS. 


CRT 


I/O output 


*For TWU/PRU1001 or TWU/PRULOO3 use "TTU8124" keyword parameter. 
For TWU/PRU1005 use "TTU8126" keyword parameter. 
For TWU/PRU1901 use "TTU8221" keyword parameter. 
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TERMNL 
continued 


SUBTYPE (continued) 


Allowed TYPE/SUBTYPE Combinations 


; | 
. TTY Line Procedure 


TN1200 


TWU/PRU1001* 
TWU/PRU1O03* 
TWU/PRU1005* 


VIP7100 
VIP7200 " - y 7 y = zs 


VIP Line Procedure 
ea CAS CPU CRT KB KCT KPR ~——~PRT 


y/79 


y/79 


(1) VIP765 
(1) VIP775 
VIP785 


VIP7700 
VIP7760 


*For TWU/PRU1OO1 or TWU/PRU1003 use "TTU8124" keyword parameter. 
For TWU/PRU1005 use "TTU8126" keyword parameter. 
For TWU/PRU1901 use "TTU8221" keyword parameter. 
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TERMNL 
continued 


SUBTYPE (continued) 


Allowed TYPE/SUBTYPE Combinations 
(continued) 


BSC Line Procedure 


(1) For VIP765/VIP775, the default address of 88 is generated for the 
second screen declared on a Station 


NOTE : In the above table, where the combination is allowed, ieee, "y'' 
indicated in the appropriate column, the default address, if 
applicable, is given as a hexadecimal value. 


mo 2-hexadecimal digit value enclosed in quotation marks to specify the 
hardware address of a terminal compatible with a standard terminal, see 
TYPE. 

Values are determined at the time of installation and are obtainable from 
the Field Engineering Service. 

The parameter is specified where the terminal address is significant and 


> must be other than the default address generated by BINS from the TYPE/STYPE 
2 combination. 
ASSIGN 


=dédicates the terminal to a particular use identified by a name ranging from 
1 thru 4 alphanumeric characters which must be, 
A - either the program queue declared by the QUEUE command 
| - or the VCAM subsystem (IOF or TDS) declared by a DCTAP command. 
{ The assignment can be altered by the MIT network control command. 


i 


on : If the terminai is declared SLAVE, then ASSIGN must not be specified. 
AUTO 


not applicable if the terminal is dedicated (ASSIGN) to IOF subsystem. 
‘ P ¥ 
y ensures that BINS automatically logs on a receive-only terminal or a master 
A y +98 
RAO terminal, iee., not declared SLAVE. 


- MCS oriented parameter which allows MAM to keep track of the terminal line 
size (LLENGTH) in order to generate a new-line or carriage-return/ line-feed 
character string before the first line of each message or whenever a line is 
filled. 

See LLENGTH. 


es i TERMNL 
Pity continued 


haa 
CIMSE i¥ * 


- specifies that BTNS must not initialize traffic to the terminal declared 
until an RT network control command is issued in order for the terminal to 
accept a connection request from the application. 


a ; 
oe The rarameter does not apply to the network control terminal designated 
v OPER, see ''name'! of the TERMNL command. 

CONTRO 


ecifies that the log-on procedure for the terminal declared is subject to 
verification of the following parameters against the system catalog, viz, 
- user identification 
- password 
+ “recount_name, pro5/HLU-F06 
The parameter can only be specified for a master terminal, ieee, not 
declared SLAVE, and must be specified if the terminal is to work with 
IOF or TDS. 
For a detailed description of the log-on procedure using the system 


catalog, see Section II and Terminal Operations GCOS Manual. 


he terminal to the MCS COBOL application, see Section IV. 
.« NL denotes normal mode which is the default value and specifies that, 
- headers and control characters are not passed to the application 
- character encoding and repeat functions are performed 
- other characters, including standard marks, are passed without 
translation. 
- MK denotes mark mode and specifies that, 
- headers are passed as marks of the form ><UO3abc 
- all hexadecimal control characters are translated into their 
corresponding marks 
- character encoding and repeat functions are performed 
- other characters, including standard marks, are passed without 
translation. 
- UN denotes unedited mode and specifies that, 
- headers are passed as marks of the form><UO3abc 
- other characters, including control characters and marks, are passed 
Xp without translation. 


eee oriented parameter which specifies the format of input data passed from 


- a 3-decimal digit value which defines the number of characters in the 
physical line length of the terminal declared, see "MCS Oriented Parameters". 
For instance, this parameter would be used by the IOF VCAM subsystem to 


DM adapt its message length tc the line iength of the terminal receiving the 
NAP message. 
LLENGTH 


= S oriented parameter which specifies the number of characters in the 
logical terminal line size to be used for automatic editing when the option 
BLOCKING is specified. 
Values range from 5 thru 9999, 
For default vaiues, see "MCS Oriented Parameters'' at the end of the TERMNL 
command. 
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TERMNL 
continued 


Pais 


{ 


a 
q 
t 


=applicable only for the BSC line procedure to specify the sub-block size in 


SY 


“" XNBLOCKS 
- S oriented parameter which defines the number of logical lines to be 


accepted in each message sent to the terminal declared. The number of 
characters for each logical line is determined by the LLENGTH parameter. 
The length of the message transmitted is defined by the algorithn, 


( NBLOCKS x LLENGTH ) = maximum length 


The part of the message surpassing this limit is truncated. 

The number of logical lines ranges from 1 thru 9999, 

For default values, see "MCS Oriented Parameters" at. the end of the TERMNL 
command. 


rom the MCS COBOL application to the terminal, see Section IV. 
- NL denotes normal mode which is the default value and specifies that, 
-~ the user provides a header for the VIP line procedure in the mark form 
><U03 abc 
- character encoding and repeat functions are performed 
- hexadecimal control characters are translated into character encoding 
mark form ><Cab 
- standard marks specific to the terminal are translated into hexadecimal 
characters 
- all other characters are passed without translation. 
- UN denotes unedited mode and specifies that, 
- the user provides a header for the VIP line procedure in the mark form 
><UO03 abc 
- other characters, including control characters and marks, are passed 
without translation. 


\ ge oriented parameter which specifies the format of output data passed 


characters to be generated by BINS when transmitting a character string. 

The sub-block mode can be uSed in either transmission, viz, 

» normal, in which checks are made for transmission and device control 
characters in order to distinguish these from graphic characters 

» transparent, in which no checks are made, ieee, all characters are 
treated as graphic characters. 

Values range from 50 thru 512. 

The default value is 80 characters. 


D 


- specifies the character string that must precede any syStem message sent by 


BINS to the terminal declared. 

The character string is expressed as a hexadecimal value enclosed in 
quotation marks and ranges from 1 character (2 hexadecimal digits) thru 4 
characters (8 hexadecimal digits). 

The default value is 2 characters ‘4 hexadecimal digits), viz, "0D25" 
which defines respectively carriage-return/line-feed. 

An "FF" value specifies that no character string must be inserted in front 
of system messageSe 


For format of network messages, see Terminal Operations GCOS Manual. 
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TERMNL 
continued 


MCS Oriented Parameters 


These parameters are only effective where the terminal functions solely thru 
MCS, iees, when not connected to a VCAM subsystem 


Default Values for MCS Parameters 


TTY Line Procedure VIP Line Procedure * 
terminal LINELG LLENGTH NBLOCKS LINELG LLENGTH NBLOCKS 


TWU/PRU1901 132 960 


1 
i TWU/PRU1001 
TWU/PRU1003 VIP765 1612 1 
TWU/PRULOOS5 | VIP775 
1 
1 


46 
VIP76&5 92 2024 
VIP7700 
VIP7760 ee ee 
haa SO 50 100 * For all VIP terminals, new-line 
function iS automatic. LLENGTH 


BSC Line Procedure 
LINELG LLENGTH NBLOCKS 


= = 9 
na = not applicable 


F 
mry vipt [of ar rrady Aimunal Arr 1° 


fF COPSOLE KURT, Rms 


~~ 
SYS, HSLLIB 


TERMNL 
continued 


Examples 


TERMNL TRO1, TYPE-VIP7700, STYPE=KCT, IM=MK, OM=¥K; 


This command declares a keyboard/screen VIP7700 named TRO1 which is to 
function in input/output mark mode when used with a program queue via MCS. 


TERMNL OPER, TYPE=TN300, STYPE=KPR, ASSIGN=TDS, AUTO, CONTROL; 


This command declares a keyboard/printer TN300 as the network control 
terminal, iee., identified to the system by the name OPER, and specifies, 
- a master terminal of TDS 

- automatic log-on for immediate connection to TDS when loaded 

- CONTROL 


Security controls and access rights are to be verified against the 
System catalog. 


EXECUTING CNC 
Executing CNC is dealt with in terms of, 
- Command Sequencing 
- When to Generate a Network 
- Run-time Prerequisites 
- Run-time JCL 
« Simulation Facility 


Command Sequencing 
The sequence of NDL commands is significant except for the COMM command. 
The rules of command sequencing are, 


- COMM - can be lecated anywhere within the deck except before the GENCOM 
command. 
« DCTAP - is required when a version cf the VCAM subsystem is to be defined. 


The command can appear anywhere after the GENCOM command so iong 
as it does not disrupt a LINE-STATN-TERMNL command sequence. 


« GENCOM - is mandatory and must be the first command specified. 


- LINE - is required for each communications line in the network. 
Following the LINE command must be all STATN and TERMNL commands 
to define the terminals on the line. 


« QUEUE - is required for each physical queue to be defined in the network. 
The command can appear anywhere after the GENCOM command so long 
as it does not disrupt a LINE-STATN-TERMNL command sequence. 


- STATN - is applicable to all line procedures except the TTY line prcce- 
dure, iee., the command only applies to a polled line. 
For the VIP and BSC line procedures, more than 1 STATN 
command can be associated with each LINE command. 


- TERMNL - is required to identify each terminal connected on the line. 
For the TTY line procedure, only 1 TERMNL command is associated 
with each LINE command. 


When to Generate a Network 
A network is generated using the H_CNC step under the following conditions, 


- There has been no previous network generated on the system disk to be used 
for communications sessions. 


- A previously generated network was destroyed in backing store (CTVF file) 
either thru a disk failure or on system restart with the CLEAN option. 


- A current network needs to be updated, for instance, 
- terminals, lines or queues to be added 
- a parameter in the NDL command(s) such as buffer unit size or line speed 
to be altered. 
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Acceptable Sequence of NDL Commands 


(only mandatory perameters are indicated) 


GENCOM names ee; 


QUEUE NLAMCe* oe 5 


DCTAP nameeece; 


QUEUE NlAMCe ee 5 


TTY Line Procedure 


LINE LNnn...; | 
TERMNL name, TYPE=terminal-type,STYPE=subtypee ee} 


LINE LNmne ee 5 
TERMNL name, TYPE=terminal-type,STYPE=subtypee..; 


QUEUE TNLAMEe ae 5 


VIP, BSC Line Procedures 


LINE LNnte ee} 


STATN name, Station-indexe ee} 
TERMNL name, TYPE=terminal-type,STYPE=subtypee ee 5 
aa anna nee 


TERMNL name, TYPE=terminal-type, STYPE=subtypeeee 5 


STATN name, sStation-indexee.; 
TERMNL name, TYPE=terminal-type, STYPE=subtypee e. 5 


LINE LNnneee 3 


QUEUE NlAMCs oe 5 


CNC Generation Main Flow 


Zomm's sessic 


either in progress 
? 


input 
enciosure 


Syntax analysis & 


system tabdles/ queues 
file checking 


abort 
tailor & fill 
comm's tables comm's 


disk 
queues 
9 


source 
iibrary 
member 


system resident 
or 
private disk 


<a 


st andar 
eguentia 
file 


preformat 
queue files 


system disk 


ae 


save comm's tablas bacxing 


copy in CTVF file 


earns 


SYS. BKST2 
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Run-time Prerequisites 


All the following prerequisites must be met to execute CNC, namely, 


No communications component must be currently active, iee, 
- BINS 
- MAM application program(s) 
- VCAM subsystem which can be one of: 
° IOF 


° TDS 
- QMAINT utility 
- Another CNC session 


Any attempt to execute the H_CNC utility will result in a "step abort" 
with the JOR message CNO4 TELECOMMUNICATIONS SESSION IN PROGRESS, sée 
Appendix C. 


MAM and/or VCAM must not be preinitialized thru the PMM "preload main 
memory'' OCL command, see System Operation : Operator Guide. 


If disk queues are specified in the NDL description, the disk queue file 
must be preallocated, see SectionIII ''Preallocating a Disk Queue File". 


On execution of the H_CNC utility, volume premounting will be requested 
thru the standard device management interface, if the volume containing 
the queue file is not already mounted. 


On successful completion of the H_CNC utility, the disk queue file will be 
preformatted. 


The following conditions must be fulfilled, namely, 


- The lines declared in the NDL description must be present and connected 
in the SRST of the system 


- The STI (station index) values declared in the STATN commands must be 
consistent with the URP firmware generation values. 
If an STI value specified does not correspond to an existing station, 
each time that the non-existent station is polled, "time-out" will occur 
thereby causing 
° response time to be increased 
© the actual station for which the wrong STI value has been given, never 

to be polled. 


The conditions cited above must be checked with the Field Engineer. 


Run-time JCL 


CNC Run-time JCL 


$JOB .job-name, USER = user-name, PROJECT = project -name3 
STEP h_CNC,SYS. HLMLIB [ oprrons= ‘srw | 3 


ASSIGN H_CR, *input -enclosure-name; 


applicable to disk queue file 
ASSIGN H QC FMS,external-file-name, SHARE =FREE, 


RESIDENT 
DEVCLASS = device-class-name,MEDIA =media-name (; 
ENDSTEP3 

$INPUT input-enclosure-name [ .zvee=parasse] ; 


NDL commands 


$ENDINPUT3; 
$ENDJ OB; 


commands retrieved from a source library member 


$JOB job-name, USER = user-name, PROJECT = project-name; 

STEP H_CNC,SYS. HLMLIB [,oprioxs = ‘sau | ; 

ASSIGN H_CR,external-file-name, SUBFILE =member-name, 

DEVCLASS = device-class-name, MEDIA = media-name2}3 
applicable to disk queue file 
ASSIGN H_QC_FMS,external-file-name, SHARE =FREE, 

RESIDENT | 
DEVCLASS = device-class-name, MEDIA =media-name {5 

ENDSTEP; 

$ENDJ OB; 
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Syntax for CNC run-time JCL : 


. $STEP statement 
- H_CNC is the system load module in the system load-module library 
SYS. HLMLIB and must be specified as given. 
- OPTIONS ="SIMU" specifies that the generation is to be used for simulation 
purposes, see "Simulation Facility" later on in the section 


- $ASSIGN statement (ist. ASSIGN in sequence) 
- H_CR is the. system-reserved internel-file-name for the file containing the 
NDL commands, either as an input enclosure or as a source library member, 
and must be specified as given. 


- $ASSIGN statement (2nd. ASSIGN in sequence) 

~ H_QC_ FMS is the system-reserved internal-file-name for the file prealloc- 
ated for disk queues. 

- SHARE=FREE denotes that the disk queue file is to be shared by BTNS and 
the active MCS COBOL application program(s) and must be specified as given 

- RESIDENT is specified if the disk queue file has been preallocated on a 
resident disk to be accessed simultaneously by MCS COBOL application pro- 
grams and system utility programs operating on the file, such as FILPRINT. 


- $INPUT statement 
- TYPE=DATASSF is used to provide for the cards in the input enclosure 
being in the form of DATA or SSF (system standard format). 


Example of Network Description as an Input Enclosure 


$JOB GENNET, USER = UNAME, PROJECT= DEPT; 


STEP H_CNG, SYS. HLMLIB; 
ASSIGN H_CR, *NETIN; 


ASSIGN H_QC_FMS, DQUEUE, DEVCLASS=MS/M400, MEDIA=VOL1, SHARE=FREE; 
ENDSTEP; 
$INPUT NETIN; 


GENCOM SD20; 

LINE LN12; 

STATN STO9, 9; 

TERMNL V771, TYPE =VIP7700, STYPE = KCT, CONTROL; 
LINE LN11,SPEED =H; 

TERMNL ROSY, TYPE = TWU1003,STYPE=KPR, CONTROL; 


LINE LNO1; 

STATN S761, 1; 

TERMNL VIP1, TYPE =VIP7700, STYPE = KCT, CONTROL; 
DCTAP TDS,SIMU =4; 

QUEUE PROG NUMBLK = 50; 

QUEUE V771, RESTART; 


$ENDINPUT; 
$ ENDJOB; 


Syntax for example of network description as an input enclosure : 


- The job generates a network from the description contained in the input 
enclosure NETIN. 


- Since disk queues are defineé in the network description, the previously 
allocated disk queue file, DQUEUE, is assigned. 
Example of Network Descripticn as a Library Member 


$JOB TCOMMS, USER = UNAME,PROJECT =WAGE; 
STEP H_CNC,SYS. HLMLIB; 


ASSIGN H_CR, SOURCE, DEVCLASS =MS/M400, MEDIA = VOL2, SUBFILE = NETWK; 
ENDSTEP; 
$ENDJ OB; 


Syntax for example cf network description as a library member : 


- The job generates a network from the descripticn stored previously as a 
member NETWK in the source library SOURCE residing on the volume VOL2. 


Simulation Facility 


The simulation facility is activated thru the SIMU option in the $STEP state- 
mente 


It allcws the user to run GNC in order to provide the syntax analysis of a new 
or updated network description without a communications session taking place 
after network generation. 


When the simulation facility is used, the run-time prerequisites to execute CNC 
jo not apply, ieee, 


» CNC can run concurrently with any combination of communications components 
and application programs interfacing with these components. 


- MAM and VCAM can be pre-initialized. 


- Values specified in the NDL commands do not have to be consistent with SRST 
values. 


If disk queues are specified, then the disk queue file must be assigned. This is 
needed to compute the size of system tables for the queues based on the size of 
the preallocated file and the type of disk (volume) containing it. The file 
specified can be one currently used by an active communications session. 


The principal effects of simulation are, 
- The communications tables are not generated 


- The disk queue file is not preformatted. 
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TUNING THE NETWORK 


Tuning the network enables the best use of the communications system in terms of 
reducing response time and optimizing memory occupancy. 


Rules for tuning fall into 3 broad categories, namely, 
- BINS/URP Tuning 
» MAM Tuning 
« Optimizing MCS COBOL Applications, see Section III. 


BINS/URP Tuning 


e network definition 


The segment containing the network description and permanently accessed 
by BINS may be set resident in memory thru the PMM OCL command. 
The segment should be made as small as possible, see Appendix G. 


Corresponding to several different communications sessions, as many 
cataloged network descriptions should be written 

The CNC step on an average of 1 minute to generate a given network 
allows rapid switching from one network operation to another. 


The constraint in changing the network is to stop BINS and any other 
communications program. Once the network has been generated, BINS takes 
about 30 seconds to be initialized. 


» BINS buffer pool size 


Points to note ; 


A message is output from a queue to the appropriate terminal connected 
to a MAM application program, only if there are enough units in the BTNS 
buffer pool to contain the message. 

On input, units in the BINS buffer pool are dynamically linked to 
receive data from terminals connected to MAM application programs and to 
VCAM subsystems. 

An overload situation occurs during a peak in traffic for too small a 
buffer pool; BINS automatically retries the transmission. 

The BTNS buffer pool occupies a segment of up to 64K bytes and is created 
at BTNS start-up and deleted on termination. 

see "Considerations for buffer pool sizes" described later on. 


Specifying the BTBFSZ parameter, see GENCOM command : 
The unit size in bytes is determined by the average message length which 
in turn depends on, 


Application requirements 
Terminal characteristics. 


Specifying the NBBTBF parameter, see GENCOM command : 

The buffer size specified by the BTBFSZ and NBBTBF parameters represents 
the maximum space required to contain 1 message per transmission line, as 
BINS may have to service ALL transmission lines simultaneously. 


ae minimum number of units necessary is as follows: 


2 units for each non-VIP transmission line, iee., TTY and BSC 
3 units for each VIP transmission line. 
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» VCAM buffer pool size 


Points to note : 

- The VCAM buffer pool is generated if VCAM subsystems are declared by 
at least one DCTAP command in the NDL description 

- The buffer pool is used to output messages to the appropriate terminal 
connected to the version of the VCAM subsystem declared. 

- The VCAM buffer pool occupies a segment of up to 64K bytes and is 
created at BINS start-up and deleted on termination. 

- see "Considerations for buffer pool sizes" described below. 


Specifying the DABFSZ parameter, see GENCOM command ;: 

The unit size in bytes is determined by the average message length 
composing the response to the terminal which in turn depends on, 

- Application requirements 

- Terminal characteristics. 


Specifying the NBDABF parameter, see GENCOM command : 

The buffer size specified by the DABFSZ and NBDABF parameters represents 

the maximum space required to handle output data to however many termi- 

nals which are interactive at any one time. 

Factors to consider in determining the buffer pool Size are, 

- 1 message for each active terminal in order to avoia suspending the 
VCAM subsystem 

- For the IOF and TDS versions of the VCAM subsystem, where 1 enquiry 
(input) generates 1 response (cutput) aS a rule, the contents of the 
buffer pool is automatically regulated by the rate of input allowed by 
BTNS and the characteristics of the line(s). 


- considerations for buffer pool sizes 


Optimum values for buffer size parameters can be adjusted for as the 
network is used. 
Factors influencing optimum values are, 
- Transmission lines are not generally active simultaneously; sharing 
buffer space is to be considered. 
- Characteristics cof the network being as follows, 
° Speed of the line 
The faster the speed of transmission, the greater the thruput of 
the buffer pool and consequently the smaller the buffer pool, and 
the quicker the "turn-around". 
° Total traffic cf the network : 
The greater the traffic, the greater the buffer pool. 
Increase in total traffic is caused by, 
- The larger number of terminals active in the network 
- The type of application; "remote batch"' applications impose a 
heavier traffic on the network than "interactive" applications. 
° Message length : 
The buffer unit size must range from %(N) to N, where N is the 
average message length. 


If buffer size parameters are not specified, equal length pools are gen- 
erated. The default size of these pools is given in Appendix Ge 
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Using the results obtained in the BTNS JOR after several communicaticns 
sessions, buffer pool sizes can be adjusted for subsequent sessions, see 
Appendix I. 


Maximum Message Length of Terminals 


Line Procedure Message 
Terminal A=Asynchronous Length 
S = Synchronous (bytes) 


TWU/PRU1OO1) 
TWU/PRULOO3 
TWU/PRULOOS5§ 


TWU/PRU1901 


VIP7E5. 


vip7100( 
VIP7200 | 
VIP7700 | 
VIP7760 | 
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- polling algorithms 
Points to note : 


- Setting up the polling list: 
The polling list for stations on a multipoint line is defined by 2 
parameters of the LINE command, namely, 
° POLLIST which lists the stations by their respective STIs (station 
index) defined in the STATN coruiands following the LINE command 
© LINPLG which defines the restart of polling after successful data 
entry on a given Station, as follows, 
- If specified, polling resumes at the beginning of the polling list, 
ieee, linear 
- If not specified, polling resumes at the next station consecutive 
to the given station, ieee, round-robin. 


- When BINS is initialized thru the ST network control command, the poll- 
ing list is loaded by BINS into the URP. 
Polling is handled by URP firmware. 


- Modifying the polling list: 
The polling list can be modified by the following network control com- 
mands, as follows, 
° HT to inhibit the station if it is known that the station is; 
- not used to send or receive, eege, closed down 
- out-of-order due to a malfunction 
- unavailable if "time-out", as specified by the value given to TOLEN, 
has occurred. 
° RT to restore the station to the polling list, 
- if HT was previously issued 
- if the STATN command was specified with the CLOSE option at the time 
of BINS start-up. 
° MTP to modify a part or the whole of the polling list. 


Specifying the POLLIST and LINPLG parameters : 
- Example 1 : Equal frequency, round-robin polling 

POLGIST = (1.4.25 3'5°43.5) 

Alli stations 1, 2, 3, 4 and 5 are as frequently polled. 
- Example 2 : Biased frequency, round-robin polling 

POLLIST = (15/2 9.05.3 -3.4.4 4554:5-5) 


Station 1 is polled 4 times more frequently than stations 
2, 3, 4 and 5. 


- Example 3 : Descending frequency, linear polling 
POLLIST=(1,2,3,4,5),LINPLG 


The stations are polled in order of descending frequency, 
namely, station 1 being polled most frequently, while 
station 5 being the least polled. 


- Example 4 : Biased frequency, linear polling 
POLLIST=(1,1,1,2,3,4,5),LINPLG 


The polling bias is heavily in favor of station 1. 
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» considerations for station declaration 


- The effects of declaring 1 station per line are, 

° A larger number of lines are used 

° A larger network description segment is needed since approximately 200 
bytes per line are needed, see Appendix G 

° The lines will not be used to their optimum capacity 

° Installation costs will be increased for either or both reasons, 
« For equipment already installed, running and maintenance costs will 

be greater 


- At the installation planning stage, more equipment than is necessary 
will be installed. 


- When using the multipoint facility, ieee, declaring more than 1 station 
per line, the gain in reducing the number of lines, must be considered 
against 
° The degradation of response time which is caused by 

- The "dead-time" of the polling mechanism 
- The time for transmitting a messege, which depends on its length 


° The type of application, ieee, interactive applications are best suit- 
ed for a multipoint network. 


- specifying the PRIRA parameter, see LINE command : 


BINS executes the following actions according to the parametric values 
specified. 
/ - PRIRA= IN/nnnn 
° When an output request arrives from MAM or VCAM, 
| - The request is executed 
\ » The line is then polled for as many times as specified by "nnnn" in 
} the parameter, each poll corresponding to 1 scanning of the station 
me index (STI) in the polling list, before 
- The next output request is accepted. 
/ ° If the line is inactive, ieee, no output pending, a continuous polling 
of the line, iee., loop in the URP firmware, is executed. 


\- PRIRA =OU/nnnn 


° When output requests are pending, iee., enqueued messages, 


- AS many messages as specified by "nnnn'' in the parameter are output, 
before 


« The line is polled again, the poll being the scanning of 1 station 
index in the polling list. 


° If no messages are to be output, the line is polled continuously. 


- }grro|aurin} 
see "Parameter Descriptions'' of LINE command. 
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=— > MAM Tuning 


- choosing between disk queues and memor ueues 
4 y gq 


When disk queues are to be used: 

° For the checkpoint/restart capability in case of "step abort" or 
"system crash!" 

® For file transfer and data collection, where the data obtained is 


used as input information to applicaticn programs to be run after the 
communicaticns session. 


When memory queues are to be used: 
° For critical response time in reducing "turn-around". 


When both disk queues and memory queues are to be used: 

° For heavy traffic loads, eg., BSC file transmission or for a large 
network, 
- Memory queues can be used to receive data 
» Disk queues can then be used to store the data. 


Example cf using both types of queues: 


° Installation environment 
« 20 VIP7700 keyboard-screen terminals 
- 4 printers to produce hard copy | 


° Application usage 
- VIP terminals are used in conversational mode to enter bills on the 
basis of 1 enquiry (input) to 1 response (output) 
- The printers are used to print out the bilis entered on the VIP 
terminals and therefore many messages may be generated for cutput te 
the printers. 


° Choice of queues 
- Memory queues are to be used for the VIP terminals and the applica- 
tion program for rapid "turn-around" 
- Disk queues for the printers since hard-copy is slower to produce 
than screen operations. 


- structure of the queued message 


The internal structure of a message when queued by MAM is the same in 
memory as it is on disk. The message is assembled in fixed length blocks 
specified by the user. 


The blocks are used as follows, 


- TCB (text control block) 
° Each TCB is structured as follows, 
- 5 bytes are used to provide the link te its appropriate HCB 
- The remaining bytes to contain the actual text of the message. 


- HCB (header control block) 
° An HCB occupies the same block size as a TCB and is structured thus, 
» HCB1 : 50 bytes to contain control information and the link to HCB2, 
The remaining bytes to link to TCBs, each link being 4 bytes. 
« HCB2 : 4 bytes to link HCB2 to HCB3, 
The remaining bytes to link to TCBs, each link being 4 bytes. 


« HCB3 : as for HCB2, but the first 4 bytes are "lost". 
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Optimizing Queue Size 


total block size to contain message = 12n bytes 
1 HCB is assumed fcr every 3 TCBs 


CASE 1 
on 


message of division of 

9n bytes in message into 

working area 9 data blocks 

structured 
of program each of n bytes : 
message with 

In case 1, the message is split unduly owing links between 
to the small size of the blocks declared. The header and text 
number cf links required slows down storage & control blocks 


retrieval, and hence increases response-times 


total block size to contain message = 12n bytes 


CASE ? 
on 


message cf division of 

9n bytes in message into 
working area 3 data blocks structured 
of progzam each of 3n bytes message with 


links between 
header and text 
control blccks 


In case 2, the blocks are larger in sizee The 
number of links are fewer compared to case l. 
Stcrage and retrieval are more rapid, thereby 
decreasing the response time. 
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The number of blocks needed to queue a message depends on, 


the length of the message 

the size cf the block in bytes defined in the GENCOM command as follows, 
© QDBLKSZ for disk queues 

° QCBLKSZ for memory (core) queueSe 


« calculating the number of blocks 


The number oc y the al 


n= message —wemerh (+ 1, for any remainder), where B=block size 


The number of HCBs is given by the algorithms 
© For 1 HCB, iee., HCB1, 

(Nx4)<(B-50) , where N=number of TCBs, and B=block size 
° For 2 HCBs, iee., HCB1 and HCB2, 

(Nx 4) < (2B -54), where N=number of TCBs, and B=block size 
° For 3 HCBs, iee., HCB1, HCB2 and HCB3, 

(Nx 4) < (3B -5&), where N=number of TCBs, and B=block size 


specifying the QCBLKSZ and QDBLKSZ parameters, see GENCOM command : 


The value in bytes must be so chosen in order 


to minimize the number of blocks needed to queue the average message, 

which in turn enables 

to reduce the "overhead" imposed by MAM on BTNS and the application 

program in terms of 

° message processing, ieee, unnecessary "splitting" of messages is cost- 
ly in CPU time 

° the number of I/O operations to access HCBs and TCBs on a disk queue 
file. 


compromise must be found between 
performance, ieee, the number of blocks to be accessed 
space utilization, ieee, minimising the amount of "lost" space, 


Example of optimizing queue size: 


Co 


oo Oo 8 


nsider an average message length of 980 bytes. 


If 3 TCBs are to be used, then 

The block size must be no less than (327+5) =332 bytes 
The "loss" in TCB3 is (327 x3) - 980=1 byte 

The "loss" in HCB1 is (332 - (50+(3x4))=270 bytes 

The total "loss" is 271 bytes. 


If 4 TCBs are to be used, then 
° The block size must be no less than (245+5) =250 bytes 
° The total "loss" is in HCB1, which is (250 - (50+(4x4)) =184 bytes. 


If 5 TCBs are te be used, then 
° The block size must be no less than (196+5) =201 bytes 
° The total "loss'' is in HCB1, which is (201 - (50+(5x4)) =131 bytes. 


The more the number of TCBs used, the less the waste but the greater the 
access timee A reasonable estimate would be a block size between 200 ana 
300 bytes which in this case happens to be about % of the message length. 
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Example of optimizing the number of blocks: 

Consider a message text to fill a screen of the following characteristics, 
- 24 lines 

- Each line containing 80 characters. 

A block size of 85 bytes has been chosen to contain the entire text per 
line, ieee, S80 bytes for the text and 5 bytes for the link. 


° to reduce response time 


Response time is reduced if BTNS can start delivery of the first lines 
of text before the entire text for filling the screen is queued. 
In order to do this, 
- Each line must be sent as a separate message, ieee, SEND WITH EMI 
- The message structure therefore must be 
- One TCB to contain the line 
~ One HCB1 to head each TCB 
- 24 TCBs and 24 HCBis are needed to contain the entire message text, 
giving 48 control blocks, each of 85 bytes, making 4080 bytes. 


The added advantage of specifying the message structure in the way des- 
cribed is Securitye 


° to save space 


In order to save space, the entire message text to fill the screen must 
be queued and transmitted as follows, 
- Each line is sent as a portion of the message, ieee, SEND without 
indicator, up to the last line 
» The last line, 24th, is transmitted by SEND WITH EMI, thereby ter- 
minating the message text 
. The message structure must therefore be 
- 24 TCBs to contain the entire message text 
- One HCB1 to link the first 8 TCBs, ise., TCB1 thru TCB8 
- One HCB2 to link the next 16 TCBs, ieee, TCB9 thru TCB24 
- 1 HCB1, 1 HCB2 and 24 TCBs are needed to contain the entire message 
text, giving 26 contro: blocks, each of 8&5 bytes, making 2210 bytes. 


A saving of 1870 bytes compared to the preceding case has been made at 
the expense of minimizing response time. 


» defining memory queue Space 
Space for memory queues is restricted to a single segment of 64K bytes. 
- The number of memory blocks is given by the algorithm 


N=SNUMBLK + QCPOOL, for NUMBLK see QUEUE command 
for QCPOOL see GENCOM command 


- The restriction on the memory queue space to be declared is 
(N x QCBLKSZ) £55535, for QCBLKSZ see GENCOM command 


- The total memory queue space declared includes 
° The pool independently reserved for the exclusive use of individual 
queues, as declared by the NUMBLK parameter of the respective QUEUE 
commands 
° The pool, as declared by the QCPOOL parameter of the GENCOM command, to 
be shared by all queues qualified by the QCPOOL option in their respec- 
tive QUEUE commands. 
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- Violating the restriction placed on memory queué space will cause an 
error during network generation with the message 


ERROR CNOO20 SEVERITY 4 SEGMENT TOO LARGE: buffer-pool-name 
For details, see "'NDL Error Messages" in Appendix C. 


e of the generated segment for memory queues is provided 
see Appendix G 


Estimating the size of the memory buffer pool depends on 
~ Message length, which has been dealt with previously. 


- Traffic loaa, which comprises 
° Time taken to compose the message text to be input 
° Time taken to key in the composed message text 
° BINS transfer time 
° Application program processing time 
© Response time in outputting the reply to the terminal. 


In the case of interactive applications, up to 30% of the memory buffer 

pool is used on an average during peak periods. 

Tailoring the buffer pool size is based on the following information, 

° At the end of the session, the BINS JOR listing, see Appendix I, gives 
information on the maximum percentage use of the memory queues segment. 

° During the session, the network control command DT QUEUE can be issued 
to take random percentages. 

Over a period of time, if the "maximum" has not been exceeded, the NDL 

parameters determining the memory buffer pool can then be reduced for a 

new network description, and the CNC utility rerun. 


- Number of queues sharing the buffer pool: 
The QCPOOL parameter of the GENCOM command enables all or part of the 
memovy buffer pool to be shared by several queues if all or some cf the 
queues are defined with the QCPOOL parameter in their respective QUEUE 
commands. 
The disadvantage of shared buffer pools is the liability of overloading. 
As a general rule, the type of queue determines the use of the buffer 


ool, namely, 
(: Ter:minal queues are more Suitable to share the buffer pool 
° Program queues are more suitable for individually reserved pools in 
order to receive several messages in a stream 


defining disk queues 


In order to use disk queues, 
- the disk queue file must be preallocated 
- a buffer segment must be generated by CNC to contain 


° a bit map to reflect the status of each block of the file, ieee, used 
or unused 


° buffers to read/write HCBs and TCBs from/to the disk file. 
The size of the buffer segment is given in the CNC report, see Appendix G 


Calculating the size of the queue file extent depends on 


- The block size defined by the QDBLKSZ parameter of the GENCOM command. 
A block size of 500 to 1000 bytes should satisfy the requirements for 
most applications. Any size smaller than 500 bytes would increase the a 
overhead for disk I/O transfers. > 
The larger the disk capacity, the larger QDBLKSZ can be. ww 


- The maximum number of blocks permitted on the file defined by the algo- 
rithn, : 


DNUMREC £32767, for NUMREC see QUEUE command 


If the total number of blocks exceeds the maximum, ieee, 32767, 
then an error message will be flagged at network generation 


ERROR CNOO25 SEVERITY 4 QUEUES FILE TOO LARGE 


For details, see 'NDL Error Messages" in Appendix C. 


- The characteristics of the disk medium, namely, 
° The number of blocks per track 
© The number of tracks per cylinder 


Disk Drive Number of Blocks Tracks/ Capacity 
Identifier per Track Cylinder Megabytes 


(7294 — QDBLKSZ) 
MSU03 10 ——————_-- 20 29 
[101 + ((2137 x QDBLKSZ) + 2048)] 


MSUO350 | 70 
MSUO400 (13165) ‘6 100 
MSU0402 (135 + QDBLKSZ) 100 
MSU0452 200 
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* preallocating disk files 


In crcger to optimize performance and céduce cespunse Limes, conlenlicn in 
accessing files should be avcided. Wherever possible, files used during the 
cummunications session should be allocated on different disks. 


- The files used must frequently in a communications system are, 


° System backing store, SYS.BKST1, for swapping code and data segments 
of the system and application programs during execution 
The file is accessed by the VMM (virtual memory management) compcnent 
of GCOS. A "bottleneck" will occur in accessing the file if memcry is 
uverluaded by tou many jobs concurrently executing. 


° The queue file which is accessed thru MAM by 
- BINS and, | 
- MAM (MCS COBOL) application programs. 


° User files which are accessed unly by MAM application programs. 


- Contention in accessing files arises in the following instances, 


° If user files and the queue file are allocated on the same disk, then 
a great number of I/O operations has to be performed by the system in 
processing messages, thereby slowing down the thruput. 

Contention arises between 
. BINS in trying to queue and dequeue messages 
- The MAM application program in trying to access both types of files. 


° If the queue file is alloucated on the system disk, and if the lcad im- 
posed on the system is such as to increase the rate of segment swapping, 
then contention is caused among 
- VMM swapping and loading code and data segments 
- BINS in trying to queue and dequeue messages 
- The MAM application program in trying to access the queue file. 


- In order to optimize file allocation cencerning disk I/Os and missing 
segments, the user has the statistics provided by the BTNS JOR listing 
and the MAM application prograi JOR. For details of the BTNS JOR, see 
Appendix I. 
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SECTION VI 


QUEUE MAINTENANCE 


QMAINT is a system utility program available tc the user toe perform maintenance 
on memory and disk queues defined for the network generated by a CNC session. 


The utility performs the following functions, 
» Prints messages from a queue 
- Purges messages from a queue 
- Sends messages to a queue 
- Displays the status of a queue 


QMAINT is described in terms of: 
- Input/Output Data 
- Command Language 
« Executing QMAINT 


INPUT/OUTPUT DATA 


The input data to QMAINT is a set of commands specified by the user, which 
describes the actions to be performed; the output data from QMAINT is in the 
form of print-outs. 


» input to QMAINT : The commands to QMAINT are introduced either on cards 
forming an input enclosure in a deck of JCL statements, 
or as a subfile retrieved from a source library. 

If the QMAINT commands are to be used repeatedly, eg, 
to display or purge the contents of all queues at the end 
of a telecommunications session, then they should be 
stored as a member of a library. 


- output from QMAINT: Print-out reports can be of the following, 


- Messages in the JOR : 
JOR messages are printed in case of fatal user or 
System errors that cause QMAINT to halt abnormally. 
A detailed description of these messages is given in 
Appendix CG. 


- SYSOUT Reports :; 
The SYSOUT report lists the QMAINT commands which have 
been executed, and after each command additional 
information specific to it is included. 
The contents and format of the QMAINT commands are 
dealt with in "Command Language" later in the section 
A summary of errors detected during the execution of 
QMAINT commands is printed out at the end of the SYSOUT 
report. 
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COMMAND LANGUAGE 


QMAINT command language is described in terms of, 


Language convention 
Command Repertoire 


Language Convention 


Commands and their parameters are written in capitals. 


The following symbols must not be employed in user-supplied values, 


» comma Slash | ( open parenthesis 


V blank. | equals 3 ) close parenthesis 


3 semi-colon asterisk ~ '™ quotation mark 


Language reserved names must not be employed in user-supplied values. 


A command can span several cards, the end of the command being terminated 
by a semicolon 


Individual parameters of a command can be separated by commas, blanks or 
commas and blanks. 


Blank cards and "comment'' cards are not processed. 


Default values are underlined; if no default is specified, a value must be 
supplied. 


The ‘sequence of commands is not significant. 


Command Repertoire 


There-are 6 commands, namely, 


COMM - defines a "'comment'"' 

PRINT - prints the contents of a queue 

PURGE - purges messages in a queue 

QSTATUS - lists status and generation parameters of queues 

SEND - sends user-defined messages to a queue 

STATUS - resumes or suspends processing of QMAINT commands in case of 
error 

commands are listed with the following information, 


Definition 

Format of Command 
Parameter Descriptions 
Command Report 

Examples (where applicable) 
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COMM 


Definition 
The COMM command defines a comment and may appear anywhere in the sequence of 
commands. 


Format of Command 


COMM "string"'s 


Parameter Descriptions 
"string" 
- a character string between quotation marks that must be opened and closed 
on the same card. 
A maximum of 72 characters can be specified for each COMM command If a 
comment is greater than 72 characters, then the excess number of characters 
must appear on a following COMM card. 


Command Report 


Only on command listing. 
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PRINT 


Definition 


The PRINT command is used to print out, without any alteration to, the contents 
of one, several or all of the queues defined within the given network. 

The contents of a queue is the set of messages that are completely queued, 
ieee, not in the transitional state of being sent or received. 

The messages are printed out in the order that they would be received from the 
queue concerned by an application program or BTNS. 


Format of Command 


name [ ,name ] nee ; 
* id 


PRINT 


Parameter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 


Name ,NaAMee oe 
- defines the list of queues and the order in which messages are to be 
printed out. 


- requests the print-out of the contents of all the queues defined within 
the given network. 
The order in which the messages are to be printed out will be the order in 
which the queues were declared at CNC generation 


Command Report 


The format of the print-out is : 


for each queue 


QUEUE NAME : name 
NUMBER OF COMPLETE MESSAGES : aaaaaa 


for each message 


MESSAGE NUMBER : bbbbbb 


OK 
MESSAGE STATUS : } mua 
MESSAGE LENGTH : cccccce 


MESSAGE CONTENTS : 
text-of-message 


PRINT 
continued 


name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 


aaaaaa 
- number of complete messages in the queue that have been printed. 
bbbbbb 
- number of the message ranking in the queue. 
CLCCEE 
- length of the message in characters. 
OK 
- complete text for the message has been printed. 
NOTALL 


- partial text for the message has been printed. 


PURGE 


Definition 


The PURGE command destroys all or part of the messages that are currently 
present in a queue, irrespective of the status of the meSsages, ieee, complete- 
ly queued, or in the transitional state of being sent or received. . 

The messages are destroyed in the order that they would be received from the 
queue concerned by an application program or BTNS. 


Format of Command 


ALL 
PURGE rane NUMBMSG = nnnnn : 
Parameter Descriptions 
name 


- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 


ALL 
- specifies that all messages present in the queue are to be destroyed. 
NUMBMSG 


-~ specifies the number of messages in the queue to be destroyed. 
The number of messages ranges from 1 thru 99999, 


Command Report 


The format of the print-out is : 


QUEUE NAME : name 


NUMBER OF DELETED MESSAGES : aaaaaa 


name 

- external name of the queue specified in the PURGE command. 
aaaaaa 

- number of messages destroyed, see ALL and NUMBMSG above. 


QSTATUS 


Definition 


The QSTATUS command lists the current status and the generation parameters of 
one, several or all of the queues defined within a given network. 


Format of Command 


QSTATUS oak [ 5 name ] eee 


Parameter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 
NaMe, NAME. 
- defines the list of queues and the order in which their status and 
generation parameters are to be listed. 
* 
- requests the listing of the current status and generation parameters of all 
the queues defined within a given network. 
The order in which this information is listed will be the order in which 
the queues were declared at CNC generation. 


Command Report 


The format of the print-out is : 


for each queue 


QUEUE NAME : name 
NUMBER OF COMPLETE MESSAGES : aaaaaa 
bbbbbb 


NUMBER OF MESSAGES IN SEND PHASE : 


NUMBER OF MESSAGES IN RECEIVE PHASE : cecece 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE : dddddd 
NUMBER OF BLOCKS USED FOR THIS QUEUE : eeeeee 
MAXIMUM NUMBER OF BLOCKS IN THE POOL :; TrELLe 
NUMBER OF BLOCKS USED FROM THE POOL : ggeeeee 


PROGRAM QUEUE 
TERMINAL QUEUE 


QUEUE ATTRIBUTES : CORE 
DISK 


[/sreax J 
[ /RESTART | 
[ /Twa] 
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QSTATUS 
continued 


name 
- external name of the queue specified in the QSTATUS command. 


aaaaaa 
- number. of messages completely queued in the current state. 


bbbbbb 
- number of messages partially sent to the queue concerned, ieee, messages 
not terminated by EMI or EGI. 


cccccc 
- number of messages partially received from the queue concerneds 


dddddd 

- number of core or disk blocks allocated to the queue concerned at CNC 
generation thru the respective parameters of the corresponding QUEUE 
command, 
- NUMBLK : number of core blocks to be used as the memory queue pool 
- NUMREC : number of blocks to be used as the disk queue file 
The text "NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE : dddddd" can only 
appear if the queue was not defined with the QCPOOL option in the 
corresponding QUEUE command. at CNC generation. 


eeeeee 
- number of used blocks among the "dddddd'' blocks reserved, see above. 
The text ''NUMBER OF BLOCKS USED FOR THIS QUEUE : eeeeee" can only appear if 
the queue was not defined with the QCPOOL option in the corresponding QUEUE 
command at CNC generation. 


fLfffft 
- total number of core blocks of the core queue pool to be shared by all 

queues qualified by the QCPOOL option in their respective QUEUE commands. 
The total number of core blocks. is defined by the QCPOOL parameter of the’ 
GENCOM command. 
The text "MAXIMUM NUMBER OF BLOCKS IN THE POOL: ffffff'' can only appear if 
the queue was defined with the QCPOOL option in the corresponding QUEUE 
command at CNC generation. 


&88888 
- number of used core blocks from the "ffffff'" blocks reserved, see above. 


The text 'NUMBER OF BLOCKS USED FROM THE POOL : gggegeg'" can only appear if 
the queue was defined with the QCPOOL option in the corresponding QUEUE 
command at CNC generation. 


BREAK 
~ applicable only to program queues, see QUEUE command in Section V. 


CORE 
- if NUMBLK parameter is specified in QUEUE command, see "'dddddd" above. 


DISK 
- if NUMREC parameter is specified in QUEUE command, see "'dddddd'"' above. 


RESTART 
- applicable only to disk program queues, see QUEUE command in Section V. 


TWA 
- applicable only to program queues, see QUEUE command in Section Ve 
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SEND 


Definition 


The SEND command sends user-defined messages to queues. 

The text of the message to be sent immediately follows the SEND command and 
can appear on several cards, each card spanning from column 1 thru 80. 

This function is used to simulate terminals and for debugging MCS COBOL 


programs without a network being declared. 


Format of Command 


SEND name [ -2xpuse = "end-of-message-string" | [ »LENcTH= anna | 3 


Parameter Descriptions 


name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section V. 


ENDMSG 
- ranges from 1 thru 5 alphanumeric characters enclosed within quotation 
marks and denotes the "marker" to be used to specify the end of the text of 
the message to be sent to the queue. 


If ENDMSG is omitted, then the message text must be terminated by a //EOM 
cards 


Either ENDMSG or //EOM is mandatory, see Example following. 


LENGTH 
- defines the length of the message in characters to be sent to the queue. 
If the length specified conflicts with the number of data cards after the 


SEND command, a warning message is displayed by QMAINT, see Example follow- 
ing. 


Command Report 


The format of the print-out is : 


QUEUE NAME : name 


OK 
NOTALL 


MESSAGE STATUS : 


MESSAGE LENGTH : aaaaaa 


MESSAGE CONTENTS : 
text-of-message 


name 
- ranges from 1 thru 4 alphanumeric characters and is the external name of 
the queue as specified in the corresponding QUEUE command, see Section Ve 


aaaaaa 


- length of the message in characters sent to the queue, see Example follow- 
inge 
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SEND 
continued 


text-of-message 


- text of the message sent to the queue is edited in a maximum of 110 
characters per line. 


Examp les 


In the following examples, data presented on the cards is left-justified, ieee, 
Starting at column 1 on the left. 


Example 1 


ADVISE TERMINAL SHUTDOWN 
SEND Q1, ENDMSG = "'END"; 


In lea and 1eb, the message to be sent to queue Qi will be 80 characters, iee, 


ADVISE TERMINAL SHUTDOWNV _.. 56 spaces V 


This is because the LENGTH parameter in the SEND command was not specified and 
therefore the entire 80 columns of the card containing the message text after 
the SEND command is sent to the queue. 


ADVISE TERMINAL SHUTDOWN ADVISE TERMINAL SHUTDOWN 
SEND Q1,ENDMSG = "END", LENGTH = 24; SEND Q1, LENGTH = 24; 


In 2.a and 2.b, the message to be sent to queue Qi will be 24 characters, ieee, 


ADVISE TERMINAL SHUTDOWN 


Using this method of specifying the LENGTH parameter, the message can be 
"tailored" exactly and no space is therefore wasted in the queue. 


6-10 


STATUS 


Definition 


The STATUS command continues or suspends the processing of QMAINT commands 
when an error has previously occurred. 


EVEN 
STATUS 4 ONLY ; 
RESET 


Parameter Descriptions 


ONLY 
- following commands are executed only if no error has occurred. 


EVEN 
- only the following command is executed when an error has previously 


occurred. 


RESET 
- resets the error count to zero. 


Command Report 


Only on command listing. 


sigs pees he 
cs oe SSP oe 


EXECUTING QMAINT 


Execut ing QMAINT is dealt with in terms of, 
» Run-time Prerequisites 
« Run-time JCL 


Run-time Prerequisites 


All the following prerequisites must be met to execute QMAINT, namely, 


» A previous CNC session describing all the queues referenced by the QMAINT 
commands must have been successfully run 


- Each Program queue referenced by a QMAINT command must be available, ieee, 
the queue must not be allocated to any application program in IN, I0 or OUT 
modes 


- Each terminal queue referenced by a QMAINT command must be available, ike, 
the queue must not be currently allocated to any application program 
- either explicitly thru a $QASSIGN statement 
- or implicitly thru the terminal connection to the application program 


Run-time JCL 


QMAINT Run-time JCL 


commands retrieved from an input enclosure 


$JOB job-name,USER=user-name, PROJECT = project-name; 
STEP H_QMAINT, SYS. HLMLIB; 

ASSIGN H_CR, *input -enclosure-name; 

ENDSTEP3; 

SINPUT input -enclosure-name [, TYPE = DATASSF] ; 


QMAINT commands 


$ENDINPUT; 
$ENDJOB; 


commands retrieved from a source library member 


$JOB job-name, USER =user-name, PROJECT = project -name; 
STEP H_QMAINT, SYS. HLMLIB; 


ASSIGN H_CR, external-file-name, SUBFILE =member-iame, 
DEVCLASS = device-class-name, MEDIA = media-name; 


ENDSTEP3 
$ENDJOB; 


Syntax for QMAINT run-time JCL : 


- The STEP statement specifies the System load-module H_QMAINT is located in 
the system load-module library SYS. HLMLIB. 


- The ASSIGN statement specifies the system-reserved internal-file-name H_CR 
as the file containing the QMAINT commands, either on cards as an input 
enclosure or as a source library member. 


Example of QMAINT Execution 


$JOB QDISP,USER = UNAME, PROJECT = WAGE; 
STEP H_QMAINT, SYS. HLMLIB; 

ASSIGN H_CR, *QINP; 

ENDSTEP; 

$INPUT QINP; 


COMM "SPECIFIED QUEUES ARE Q1,Q2,Q3,Q4' 

COMM "DISPLAY STATUS OF ALL THE QUEUES"; 

QSTATUS *; 

COMM "PURGE Q1(ALL MESSAGES) AND Q2(ONLY 5 MESSAGES)"; 
PURGE Q1,ALL; 

COMM "CONTINUE EVEN IF WRONG RESULT FROM PURGE"; 
STATUS EVEN; 

PURGE Q2,NUMBMSG =5; 

COMM "PRINT CONTENTS OF QUEUE Q3"; 

PRINT Q3; 

COMM "SEND ONE 17 CHARACTER MESSAGE TO Q4"; 

SEND Q4, ENDMSG = "ENDMS"', LENGTH = 173 

TERMINAL TO LOGON 

ENDMS 


$ENDINPUT; 
$ENDJOB; 


The job defined by QDISP executes on the queues specified by the current net- 
work. The maintenance actions to be performed are described by the QMAINT com- 
mands in the input enclosure. 


SECTION VII 


DYNAMICS OF COMMUNICATIONS 


Events occurring during a communications session are governed both by the user 
and the system. 


The determining factors are, 

Execution chronology of the software components 
- Levels of simultaneity for communications 

- Optimum priorities for the software components 
- Data flow during message exchange. 


- Allocating memory resources 


EXECUTION CHRONOLOGY OF THE SOFTWARE COMPONENTS 


Before any communications session.can take place, a communications environment 
must first be created. The H_CNC utility, see Section V, is used to generate the 
network. The network is successfully created by the absence of error conditions 
during generation. 
BINS (basic terminal network support), an MCS COBOL step or a VCAM subsystem 
(virtual communications access method) can then be started. 
The two VCAM subsystems are, 

- IOF (interactive operation facility) 


- TDS (transaction driven system). 


Whenever backing store is destroyed, the H_CNC utility must be executed again 
« the H_CNC utility must be rerun 
the option MAM=YES or MAM=REFORMAT must be specified at system initializa- 
tion if disk queueing is involved (MAM=YES is the default option). 
Backing store is destroyed . 
- either thru a disk failure 
- or when the CLEAN option is specified at restart. 


Further constraints in determining the order in which the software components 


are executed, are : 
- H_CNC utility cannot be run when any communications component is currently 


executing, and vice verSae 


BINS cannot be run when another occurrence of BINS is currently executing. 


» A VCAM subsystem cannot be run if another version of the same VCAM subsystem 
is currently executing. 


An MCS COBOL step with a $QASSIGN statement specifying a queue currently 
allocated to another MCS COBOL step cannot be run 


Failing to comply with any of the above constraints will lead to a step aborte 


LEVELS OF SIMULTANEITY FOR COMMUNICATIONS 


Within the limits for operability as previously defined, communications compo- 
nents can be started and terminated independently for as long as the maximum 
system multiprogramming level is not exceeded. 


The following occurrences illustrate the levels of simultaneity for a communi- 
cations Session, 


1, 


36 


6. 


7° 


10. 


11. 


A data collection MCS COBOL application DATCOLL starts. 


Its function is to empty disk input queues filled by BTNS during a previous 


SeSsiOne 
Number of Simultaneities : 1 


A data distribution MCS COBOL application DATDIST starts. 
Its function is to distribute to output queues messages generated by a 
batch program during a previous session. 


Number of Simultaneities : 2 


A TDS job is launched. 
- The job requests connection to BINS and is enqueued. 
- TDS, however, remains available to batch entries. 


Number of Simultaneities : 3 


A TDS batch entry Starts. 
The batch entry requests connection to TDS to execute file updates. 


Number of Simultaneities : 4 


DATDIST has completed distributing all messages to output queues and termi- 
nateSe 


Number of Simultaneities : 3 


A file enquiry MCS COBOL application FILEINQ starts. 
The application awaits requests to be received into its input queues. 


Number of Simultaneities : 4 


BTNS now starts, which results in the following, 
- The network is initialized. 
- The TDS job request is now accepted , see 3. 
- Log-on requests from terminals to connect to defined input queues and 
TDS are accepted. 
- The distribution of data enqueued by DATDIST to the terminals connected 
to input queues is now Started. 


Number of Simultaneities : 4 (BTNS is a service job) 

DATCOLL has completed emptying the disk queues and terminates. 
Number of Simultaneities : 3 

The TDS batch entry, see 4, has updated its files and terminates. 
Number of Simultaneities : 2 

TDS now terminates as it is no longer required. 

Number of Simultaneities : 1 

FILEINQ has accepted all enquiries from input queues and terminates. 


Number of Simultaneities : O 


12. BINS is retained in the system to fill disk queues. 
This operation would be continued in a following session by launching an 
application DATCOLL, see 1. 


Number of Simultaneities : O 


13. A shutdown is issued. 


BINS terminates and the communications session ends. 


OPTIMUM PRIORITIES FOR SOFTWARE COMPONENTS 


In order to maintain efficient response times at terminal level, appropriate 
dispatching priorities for communications components must be chosen. Batch jobs 


are given low priorities 
The user specifies a job 
dispatching priority and 
For a description of the 


as they are not subject to real-time contraints. 


class which determines the scheduling priority, the 
the associated level of multiprogramming for the job. 


use of job class, see System Management Guide. 


The following example illustrates the effect of job class on priorities. 


Priorities for MCS COBOL & VCAM 


MCS VCAM 
variable COBOL subsystem 
step (if TDS) 


job class 


scheduling 
priority 


dispatching 
priority 


multi- 


programming 


Explanations for example 


showing priorities for MCS COBOL and VCAM : 


- H_CNC and H QMAINT utilities are not included as they are not subject to 
real-time constraints and can therefore be executed as normal batch jobs of 


class P, Say. 


- The dispatching priority for the MCS COBOL step and the VCAM subsystem, eg, 
TDS, are the same. In order to avoid conflict when both components are avail- 
able in the system, the application programmer should exercise care. 
Indiscriminate program queue scanning for data by the application program 
can degrade system performance. This could be as a result of the programmer 


specifying a RECEIVE 


Statement with NO DATA clause or an ACCEPT statement in- 


stead of building a suitable queue structure and using one of the scanning 


techniques provided. 


- The level of multiprogramming for the MCS COBOL step and the VCAM subsystem 
is the default value and can be modified by an OCL command, see System 


Operation : Operator Guide. 


DATA FLOW DURING MESSAGE EXCHANGE 


Message exchange follows a prescribed path and involves the following types, 
- Exchange between an MCS COBOL program and a terminal using a memory queue 
- Exchange between an MCS COBOL program and a terminal using a disk queue 
- Exchange between a VCAM subsystem and a terminal. 


Exchange between an MCS COBOL Program and a Terminal using a Memory Queue 


Exchange between 
MCS COBOL Program and a Terminal using a Memory Queue 


MCS 
BINS MAM COBOL 


buffer memory pee a 
pool queues 


RECEIVE 


INPUT 
WORK AREA 
OUTPUT 
WORK AREA 


Explanations for example of exchange between MCS COBOL program and a terminal 
using a memory queue, 


1. When the line is polled, terminal T sends a message which is stored in the 
BINS buffer pool. 
Buffer units are dynamically allocated by BINS as required by message length. 


2. Control characters and marks are translated according to terminal type and 
data format for input. 


3. BINS stores the message in the memory input queue to which the terminal is 
connected by issuing a call to the MAM "send" procedure. 
A "send" procedure is performed for each buffer unit to be transferred. 


4. When the program issues a RECEIVE statement to the symbolic input queue, the 
message or a part of it, is moved into the program's input work area. 
As many RECEIVE statements as necessary are issued to collect the complete 
message. 


5. When the message is to be sent to the terminal, the program issues a SEND 
Statement to the symbolic output queue, and the message is transferred from 
the program's output work area to the memory output queue associated with the 
terminal. 
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6. When the output request is located, BTNS issues a call to the MAM "receive! 
procedure to store the message in the buffer pool. 


A "receive'' procedure specifying the length and address is performed for each 
buffer unit needed to contain the message. 


7. Control characters and marks are translated according to terminal type and 
data format for output. 


The translation can be either "normal'' or "unedited'. 


8 The message is then transferred from the buffer pool to the destination ter- 
minal T. 


Exchange between an MCS COBOL Program and a Terminal using a Disk Queue 


Exchange between 
MCS COBOL Program and a Terminal using a Disk Queue 


MCS 
BTNS MAM COBOL 


buffer memory Era 


queues 


WORK AREA 


Arrows show data flow from terminal 
to MCS COBOL program. 

The process is identical in reverse 
from MCS COBOL program to terminal. 


Explanations for example of exchange between MCS COBOL program and a terminal 
using a disk queue, 


1, When the line is polled, terminal T sends a message which is stored in the 
BTNS buffer pool. 


Buffer units are dynamically allocated by BINS as required by message length. 


2. Control characters and marks are translated according to terminal type and 
data format for input. 
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3. When BINS issues a call to the MAM "'send'' procedure to store the message in 
the disk-input queue to which the terminal is connected, the following 
events take place, 

» The message is first moved to the disk I/O buffer pool 
- The message is then written to the disk queue file. 


Disk access for BTNS is asynchronous which means that BTNS does not have to 
wait for the completion of an I/O operation 


4, When the program issues a RECEIVE statement to the symbolic input queue, the 
following events occur, 
- The message is read from the disk queue file into the disk I/C buffer pool 
- The message is then moved into the program's input work area. 


Disk access for the program is synchronous which means that the program must 
wait for the completion of an I/O operation 


Exchange between a VCAM Subsystem and a Terminal 


Exchange between 
VCAM Subsystem and a Terminal 


STANDARD ; 


BUFFER POOL 


SPECIAL VGA 


; BUFFER POOL 


VCAM subsystem means one of the following : IOF, ROF and TDS 


Explanation for example of exchange between a VCAM subsystem and a terminal, 


1. A transaction is initiated at the terminal T. 
The message is stored in the BINS standard buffer pool, occupying as many 
buffer units as required. 


2. The message is then moved to the VCAM work area specified at the generation 
of the specific version of VCAM. 


3. The message activates or is processed by 1 or several transaction processing 
routines (TPR). 


4. A reply to the terminal is moved from the VCAM work area to a special VCAM 
buffer pool also specified at the generation of the specific version of VCAM. 


5. The message is then delivered from the buffer pool to the destination termi- 
nal. 


ALLOCATING MEMORY RESOURCES 


Multiprogramming in a virtual memory environment may lead to an overload situa- 
tion where several programs compete for memory resources. 


The 


The 


The 


effects on the communications sesSion are, 

segments of its components not currently executing may be swapped with 
batch programs 

these segments, when needed to process a message on arrival, must then be 
reloaded, causing 

- a tremendous increase in system overhead 

- a considerable increase in response time 

- a degradation of overall thruput. 


problems to be solved are, 
avoiding memory overload of the system 


The sum of the ''working sets'' of programs executing concurrently must not 
exceed the physical memory size available 


guaranteeing minimum memory resources 


In order to ensure rapid "'turn-around", segments of communications compo- 
nents needed to process specific data, must be retained in memory even if 
inactive over long periods. 


solutions are, 
using the $SIZE (JCL) statement 


The $SIZE statement declares the "working set" of the program for the 
purpose of controlled scheduling to avoid memory overload. 


using the MAXMEM and MINMEM parameters of the $STEP (JCL) statement 


- MAXMEM : Used for tuning the "working set'', and should be discontinued 

when the optimal size has been determined 

The facility ensures that 

° the amount of memory allocated will never be less than the 
DWS (declared working set) specified in the $SIZE statement 

° the system will not attempt to execute the step if the amount 
of physical memory available is not greater than or equal to 
the DWS, even if the step could be run on less, ieee, the 
step does not benefit by the gradual release of memory re- 
Sources as the system load decreases. 


- MINMEM : Used after the optimal DWS has been determined to allocate per- 
manently to the step a memory resource equal to the DWS what- 
ever the load of the system may bee 
The facility is used when "turn-around" times for the communi- 
cations session are slow, indicating that the components needed 
for processing are absent in memory. By guaranteeing "minimum 
memory'' requirements, all communications components needed for 
the session will be present in memory until termination. 


using the PMM (OCL) command 


In order to ensure the presence of system functions, the PMM command can 
be used to ''lock'"' these segments in memory so that these become permanent - 
ly available. 
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MCS COBOL (MAM) Application Programs 


- determining the DWS parameter of $SIZE 


run-time JCL for estimating DWS 


| STEP «eee MAXMEM; | 


| SIZE dws-vaiue . eo5 | 


The first time that the step is executed, the dws-value specified for 

$SIZE is calculated from the linkage listing of the program, see "Linking 

MCS COBOL Programs" in Section III. 

The JOR listing at the end of the job step will indicate the number of 

missing Segments, if any. 

The general rule in tailoring dws-value specified in units of K bytes is, 

- If few missing segments are indicated, a smaller dws-value can be speci- 
fied until such a time that an increase in missing segments occurs 

- If many missing segments are indicated, then a proportionately higher 
dws-value should be specified. 

Successive executions of the job step will ultimately give an optimum 

dws-value. 


guaranteeing memory 


run-time JCL for normal execution 


STEP eee MINMEM; 


SIZE dws-value eee; 


The dws-value spécified is the optimum value estimated over successive 
job runSe 


MAM and VCAM 


Both MAM and VCAM are system functions which can be "locked" in memory by the 


PMM 


BINS 


command, the format and function being as follows, 
PMM VCAM : VCAM segments are "locked" when running IOF, ROF or TDS. 
PMM MAMM : MAM segments managing memory queues are "locked". 


PMM MAMD : MAM segments managing disk queues are "locked". 


BINS runs automatically under MINMEM when initialized by the ST network control 
command. It communicates to the system the memory size needed according to the 
configuration present. 


APPENDIX A 


TERMINAL CONFIGURABILITY 


The following tables provide the user with information concerning the cunfigu- 
rability of the terminal types supported by GCOS64 in terms of, 


« access methods and subsystems supporting the terminal 


- optional hardware features (auxiliary devices or terminal subtypes) support- 
ed and the rescrictions, where applicable 


_,. types of links supported, namely 
- point-to-point 
- multipoint 


- NDL name of the terminal declared for CNC generation and its corresponding 
marketing identifier 
(several compatible terminals known by different identifiers can be declared 
under the same NDL name in tne TYPE parameter of the TERMNL command) 


- software and firmware releases, where applicable, supporting standard termi- 


nals connected to the Lo4& host computer. 


The terminals are arranged in the order of their line procedures, see ''Types of 
Standard Terminals" on page 5-24. 


For supplementary information on the auxiliary devices supported with the stan- 
dard terminals, see "Allowed TYPE/SUBTYPE Combinations" on pages 5-25 and 26. 


Terminal Types Applicable to MAM and VCAM Subsystems 


VCAM Subsystems 


Type Model 


MAM TDS IOF 


™300/1200 TermiNet 300/1200 


TWU/PRULOOL TWU/PRU1001 


_ TWU/PRU1003 TWU/PRU1OO3 


TWU/PRU1LOOS TWU/PRU1005 


TTY 33/ 35/37/38 Teletype 33/35/37/38 


VIP7100/7200 VIP7100/7200 


VIP765/775/785 VIP 765/775/785 
TWU/PRU1901 TWU/PRU1901 
VIP7700 VIP7700/7700R/7705 
VIP7760 VIP7760 

HL62 62 (any model) 
HL64 64 (any model) 
HL66 66 


Note: 1. Where no entry is made for the access method, the terminal type is 
not supported. 


2. * denotes, that IOF does not support auxiliary devices (subtypes) as 
printer (hard copy), cassette, disk or diskette. 
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Terminal Types and Link Usage 


a a nn ern eee 


Point-to-Point 


i ee 
| Type 


| | | | 


switched | through 
(1) modems 
Y _ 


. Hf. 


: leased 
(W8 cable) | (modems) 


| 


switched 


TN300/1200 


TWU/PRU1001 Y 


TWU/PRU1003 Y 


TWU/PRU1005 Y 


TTY33/35/37/38 Y 


VIP7100/7200 Y 


| 


| 


VIP765/775/785 


TWU/PRU1901 


VIP7700 


VIP7760 


Note: 1. Switched lines can be with or without automatic call detection. 


2. Multiple Interface Unit, see "Types applicable to MAM and VCAM". 
3. Require "direct timing source" option for the terminal. 


Note: No entry denotes that the link is not supported. 


Terminal Types and Software/Firmware Support 


TermiNet 300/1200 


TN300/1200 


TWU/PRU1001 


TWU/PRU1001 


TWU/PRU1003 


TWU/PRULOO3 


TWU/PRU1005 TWU/PRU1LOO5 


TTY 33/35/37/38 Teletype 33/35/37/38 


VIF 7160/7200 


VIP 7100/7200 


VIP765/775/785 


VIP765/775/785 


TWU/PRU1901 


TWU/PRU1901 


VIP7700 VIP7700/7700R/7705 


VIP7760 Firmware - 
Revision 6 
(59733684 - 006) 


VIP7760 


VIP7760 


HL62 62 (any model) GCOS62 - Release 4 
BSC2780 Package 

HL64 64 (any model) GCOS64 - Release 0400 
BSC2780 Package 

HL66 66 GRTS 3 Release 2H 


GCOS 3 Release 2H 


Note: Where no entry is made in "Software/Firmware Support", the information 
is not applicable. 
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APPENDIX B 


The information concerns the programming interface fcr terminals under either 
MCS or TDS. 


In the text for each line procedure, except the BSC2780 line procedure, 
non-graphic codes are described for ease of interpretation, in mark re- 
presentation ><, see Section IV. 


The COBOL programmer must interpret this representation to match one of 
the following two requirements, 


- if for TDS, then the TDS code representation conventions 
- if for MCS, then the mode of transmission selected for programming. 


In the case of the BSC2780 line procedure, certain control characters 
reserved for the procedure must not be used by the application program. 
These control characters are given in the tables "Specific Transparent 
Control Sequences" and "BSC Controls and EBCDIC Representation" in the 
BSC2780 line procedure. 


Terminals are classified into 3 groups, each group comprising a number of com- 
patible terminals sharing a common line procedure, namely, 


- TTY 


e VIP 
» BSC 


For a detailed list of terminals supported for each line procedure, see page 
5-24 and Appendix A. . 


Apart from using the same line procedure, terminals are compatible when they 
function as follows, 


« from the point of view of hardware/firmware, 
- they share the same TCT (transiation control table) 
- they are connected over the same multipoint line when using a '"'poll/select" 
facility 


« from the point of view of the application program, 
- they share the same controls for formatting the character image. 


Information is treated as in the following order, 


- general information is given for each line procedure, which for ease of re- 
ference are listed in alphabetical order, and not according to their groups, 
namely, 

- BSC2780 line procedure 


- TTY line procedure 
- VIP line procedure 


» detailed information is given for each terminal, where available, within the 
group, in terms of their control codes for 
- terminating messages 
- eraSing functions 
- inserting VIP headers 
- activating auxiliary devices (terminal subtypes) 


- the terminals are headed by the name of their line procedure followed under- 
neath by its NDL name declared at CNC generation; within the line procedure, 
terminals are listed in alphabetical order. 


This appendix is to be treated as a continuation of Section IV, giving in detail 
information specific to terminal programming. 


BSC2780 LINE PROCEDURE 


GCOS64 communications software provides the user with the facility for data ez- 
change under the BSC2780 line procedure cver 
- private or leased point-to-point lines (BSC1) 


val ists wig AC! nk era = Bix 2 
e S#itcnea point-to-pcint lines (BSC2). 


Communications is established between a Level 64 host computer and any of the 
following CPUs, 


- Level 62 (L62) 
- Level 64 (L64) 
- Level 66 (L66). 


The link provides a program-to-program communications facility. 
On the L64 host computer side, the programs supported can be 


« a user-provided MCS COBOL application. 


As the facility only concerns program-to-program communication, the BSC2780 
line protocol dces not include automatic processing of end-to-end control cha- 
racters defined for the BSC2750 IBM-type terminal, which are, 

« ESC 2 eScape, output device selection 

- HT : horizontal tabulation, positioning 

- EM : end-of-medium, variable data length delimiter. 
Since these control characters appear within the user text, they may be handled 
directly by the MCS COBOL application program 


Documents for reference are: 


For Level 62 communications, 
AW39 : Series 60 (Level 62) BSC1/2 Commynications 


For Level 66 communications, 


DD40 : Level 66/6000 Remote Terminal Supervisor (GRTS) 
DD48 : Level 66/6000 GCOS Network Processing Supervisor (NPS) 


BSC2780 LINE PROCEDURE 


LINK STATES 


Except where explicitly defined, the state of the link is completely controlled 
by the system thru BTNS and the URP firmware. The state of the link between two 
Stations using a common communications facility determines their connection and 
data exchange. 


The link can be in one of the following states, 
- disconnected state 
- control state 
» message transfer State. 


Disconnected State 


The link can be in the disconnected state only in a switched network environment. 
This state prevails when, 
« the physical path is not currently established over the network 
« the dialing procedure is in progress but not yet gbmpleted 
e the disconnect control sequence DLE EOT has been issued when the link 
has been idle for longer than the inactivity time-out. 


The disconnected state iS entered from one of the other two states; however, when 
leaving the disconnected state, the link always enters into the control state. 


Control State 


The link is in the control state when the corresponding physical data path is 
present but no data transmission is in progress. 


The physical data path is established after the successful completion of the con- 
nection phase at line initialization. 


In the control state, one of the two conditions can occur, namely, 
» the link may be idle, iee., absence of transmission 


- If the link is supported by a permanent point-to-point type connection, 
the idle condition persists until the transmission phase is initialized. 
When the phase is started, the L64 host computer begins to monitor the 
line for as long as the line stays open. 


- If the link is operated over a switched network, the idle condition is 
entered from the disconnected state on successful completion of the dial- 
ing procedure. 

The L64 host computer then monitors the line until a disconnect control 
sequence is issued for inactivity time-out. 


- infurmation exchange may take place between two stations 


Information exchange involves the transmission of control blocks and reply 
blocks. Initialization and termination phases of the transmission are exe- 
cuted in the control state. 
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BSC2780 LINE PROCEDURE 


Contention between two point-to-point stations arises when both bid for the 
line at the same time in order to transmit. . 


The station that wishes to transmit bids for the line by sending the 

ENQ control character as a transmit request to the other station 
If the request is accepted, the link is brought into the message transfer 
state and the requesting station can then transmit; otherwise, the link 
remains in the control state. 
If the request is rejected, bidding for the line is retried three times. 


BINS starts bidding for the line each time a new output request is made to 
it while the line is idle. 

If the line is in the logical "open" state, BINS accepts a transmit re- 
quest over ite 


In order to resolve contention, one of the stations is designated the 
"primary'' station while the other is designated the "secondary" station. 


Attributes of designating priority to the stations are, 

- if simultaneous line bids occur, the "primary" station transmits first 

- the "primary" station persists bidding to a maximum of three times until 
it receives an appropriate reply; any ENQ control received by the 
"primary'’ station once it has taken action to request the line is ig- 
nored 

- the "secondary'! station must respond to any valid ENQ control that it 
may receive 

- before re-issuing the transmit request, the "primary'' station has a 
shorter time-out when waiting for a reply than the "secondary" station, 
thus forcing both stations out of contention | 


According to the URP firmware generation, the L64 CPU may be defined ei- 
ther as a "primary" or "secondary" station. 


Message Transfer State 


The message transfer state is a dynamic state which prevails as long as messages 
and the replies they generate are transferred over the line. 


The state is entered at the start of the first message by the start control se- 
quence SOH STX or DLE STX and will be maintained thruout the entire transmiss- 
ion until the last message ended with ETX has been successfully transferred. 

An end-of-transmission control signal EOT is then issued to reset the link to 
its control state. 

The return to the control state can be achieved by the MCS COBOL application 
program thru either KCO or BCO. 


In the message transfer state, the station functions in one of two ways, namely, 
» master Station 


The master Station transmits control characters and block check characters 
containing redundant information for checking purposes. 
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- slave station 
The slave station receives data and transmits replies. 


Station functions are interchangeable and are maintained for as long as the link 
Stays in the message transfer state. 


For error free transmission, the master station is responsible for resetting the 
link on termination. However, if an error condition arises whereby transmission 
can no longer proceed, either station may reset the link to discontinue dialog. 


LOG-ON PROCEDURE 


An easy way to establish the logical connection between a remote BSC station and 
a program queue is to dedicate it to the queue, ieee, the corresponding TERMNL 
command must be declared with the ASSIGN and AUTO parameters, see Section V. 


In this case, the connection is established as soon as the line is in the con- 
trol state and remains until the line returns to the disconnected state. For a 
L64-L64 connection, the link-up may be established on both sides. 


If the user wants the remote station to be connected to different application 
programs, ieee, different program queues, the corresponding TERMNL command must 
only be declared with the AUTO parameter. 
In this case, the remote application program handles the log-on procedure as if 
it were the terminal operator, namely, 

- sending a $*$BRK signal 

» answering, where applicable, subsequent questions posed by the site cv.ntrol- 

ler if the CONTROL parameter had been specified in the TERMNL command, see 


Terminal Operations GCOS Manual. 


ENCODING DATA 


Functionally the BSC2780 line protocol allows two categories of user-provided 
data to be exchanged over a line, namely, 

e text 

- heading 


Text 


Altho ASCII encoding is a function of the BSC2780 line procedure provided 
thru the TCTNM parameter of the appropriate LINE command, exchanges be- 
tween Series 60 CPUs are performed in EBCDIC code (internal code, which 
is the default option). 


For more efficient recovery purposes, text may be split into subblocks 
separated by sequences of control characters irrespective of the mode of 
transmission. 


BSC2780 LINE PROCEDURE 


Text may be transmitted in either of the following two modes, depending 
on the requirements of the application program, 


- normal mode : 
the text must not contain any control characters or sequence of con- 
trol characters significant to the BSC2780 line procedure. 


- transparent mode ; 
the text may contain unrestricted coding of data since ail control 
characters including the "escape'' character DLE must be preceded by 
DLE to be recognized as a control function. 


The transparent mode is used prinicipally to transmit 
° binary data 

floating point numbers 

packed decimal data 

specialized or foreign codes | 

machine language computer programs 
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Specific Transparent Control Sequences 


Control 


Meanin 
Sequence S 


transmits the control character DLE in transparent mode 
forward abort, to denote end-of -transparent mode 
end-of-transmission block, to denote end-of-transparent mode 
end-of-text, to denote end-of-transparent mode 


end-of-intermediate block, to denote end-of-transparent mode 


Start-of-text, to denote start-of-transparent mode 


synchronous idle 


Control 
Character 


ACKO * 
ACK1 
DLE 
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BSC Controls and EBCDIC Representation 


Meaning in Control State 


can receive 


can receive 


can you accept transmission? 


drop synchronization and 
return to control state 


cannot receive 


time-fill 


request to stop transmiss-~- 
ion and accept messages 


establish character synchro- 
nization: discard character 


transmission begins later: 
respond with NAK or WACK 


request later and wait until 
acknowledged 


* Line Turn-around 


Meaning in 
Message Transfer State 


even block received OK 
odd block received OK 
Start of tranSparent mode 


between blocks: repeat last 
response 


end block: ignore block, 
respond with NAK 


drop synchronization and 
return to control state: 
text invalid 


end-of-block 

end-of-text (transmission) 
end-of-intermediate record 
end-of-intermediate record 


block does not check: 
retransmit 


time-fill 


message received OK: I 
would like to transmit 


Start-of-block header 
Start-of-block 


establish character synchro- 
nization: discard character 


transmission continues later] 
respond with NAK or WACK 


current block received OK: 
requ-s‘. later and wait until 
acknowledged 


Heading 
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Heading characters which are separated from the text in the message can be only 
transmitted in normal mode in one of the following ways, 

- within messages containing any type of text (normal or transparent) 

» alone in a message. 


Heading is regarded as control information used by applications for end-to-end 
control related to text data block(s) following. 


GENERAL FORMAT OF DATA MESSAGES 


SYN SYN SYN 
SYN SYN SYN 


SYN SYN SYN 
SYN SYN SYN 


SYN SYN SYN 


SYN SYN SYN 
transparent 


SYN SYN SYN 


SYN SYN SYN 
transparent 


SYN SYN SYN 
SYN SYN SYN 
SYN SYN SYN 


SYN STX text ETB BCC PAD 
SYN STX text ETX BCC PAD 
SYN STX ct ITB BCC SYN SYN text ITB BCC SYN SYN text ETB BCC PAD 
SYN STX ITB BCC SYN SYN text ITB BCC SYN SYN text ETX BCC PAD 


Transparent Text 


SYN DLE STX transparent text DLE ETB BCC PAD 


SYN DLE STX transparent text DLE ITB BCC SYN SYN DLE STX 
text DLE ETB BCC PAD 


SYN DLE STX transparent text DLE ETX BCC PAD 


SYN DLE STX transparent text DLE ITB BCC SYN SYN DLE STX 
text DLE ETX BCC PAD 


Heading 


SYN SOH heading ETB BCC PAD 
SYN SOH heading STX text ETX BCC PAD 


SYN SOH heading DLE STX transparent text DLE ETX BCC PAD 
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Explanation of General Message Format 


SYN SYN SYN SYN : 

to establish and maintain synchronization 

The number of SYN control characters to be inserted by the URP is defined thru 
the ININS parameter of the LINE command at CNC generation 

The default value of the number of SYN control characters is 4. 


STxX. * 
Start-of-text 


text or transparent text 
normal or transparent text respectively 


ELB 3 
end-of-transmission block. 
Direction of transmission is retained and another block terminated by either 
ETB or ETX must follow the current block, if the current block was correctly 
received in the first place. 


BCC : 

block-check-control character. 

The accumulated parity checking control character is checked or generated by 
URP firmware. 


PAD :. 

Trailing padding control character which has the EBCDIC value of FF. 

The number of PAD characters is defined thru the BADNB parameter of the LINE 
command at CNC generation. 


ETX : 
end-of-text; the current transmission is terminated and the direction of trans- 
mission may now be reversed if the control message EOT is sent following the 
last message correctly received. 


ITB : 
end-of-intermediate transmission block. 
See "Subblocks" later in the specification. 


DLE : 
data-link-escape used to provide, 
- Supplementary line control characters by combination with another character, 
Example : DLE @ is interpreted as RVI (reverse interrupt) 
« transparent mode control characters, see "Specific Transparent Control Se- 
quences" earlier on in the specification 


SOH : 

start-of-heading defining the start of the control information between, 
« SOH and STX or ETB in normal mode 

-» SOH and DLE STX in transparent mode. 


BSC2780 LINE PROCEDURE 


Message Structure Seen by BTNS 


ext message exchanged between the BINS message processing routines and the 
firmware can take one of three formats, namely, 


° 
q 
_ 


1. User-defined header message 


2. Message partitioned into blocks 


i—<——— optional —— 


3. TranSparent text message (non-standard codes accepted) 


i—_— optional ——» 


EXPLANATION OF TERMS 


oop ae 
Station index, set to 1 and defined by the STATN command at CNC generation, see 


Section V. 


TRI ; 
terminal index, provision for multipoint handling 


SOH : 
Start-of-heading 


header-text : 
contents are user-defined 


STX : 
start-of-text, indicating transmission in normal mode 


DLE STX : 
start-of-text, indicating transmission in transparent mode, see "Specific 


Transparent Control Sequences" earlier on in the specification 


DLE : 
data-link-escape used with either ETB or ETX to denote "end-of-block" or '"'end- 
of-text'' in transparent mode. 


ETB/ETX : 
Nend-of-block" or "end-of-text' in normal mode if not preceded by DLE, see DLE. 
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Message Structure Seen by the Application Program 


The mark symbols used in the formats below are not transmitted over the line. 


A message as Seen by the MCS COBOL application program has the following general 
structure, 


e« emission 


><KCO 
[ ><vos. header-text ><uos }[><voe]] 3S] text 


e reception 


| ><vos header-text ><vos | text 


EXPLANATION OF TERMS 


><U04 : 


start of a user-provided heading 


><U05 : 


end-of -header 


><uode : 


the text following the control must be sent in transparent mode 


><BCO : 
communication is "broken" after sending the next end-of-file block terminated 
by ETX. 


><KCO : 
communication is "kept'' (retained) after sending the next end-of-file block 
terminated by ETX. 


text ; 
user-defined message 
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MANAGEMENT OF DATA TRANSFER BY APPLICATION 


Once the link has been established and set in the correct state to perform data 
transmissions, the station whose turn it is to send data, retains its turn under 
the following conditions, 
- as long as it sends message blocks terminated by ETB for normal mode or 
DLE ETB for transparent mode 
- until it sends a block terminated by ETX for normal mode or DLE ETX for 
transparent mode in which case, the link state can be one of either, namely, 
- retained in the transfer state so that a new line bid is not necessary for 
resuming transmission in the same direction 
- returned to the control state by sending EOT after the last block 
- unless RVI (reverse interrupt) has been issued by the receiving station, see 
"Reverse Interrupt" later on in the specification. 


Unlike other line procedures for which BINS manages the control characters, the 
user application, in the case of the BSC2780 line procedure, can control those 
control functions affecting the line usage thru the MCS interface. 


Emission 


The user application program can control the turn thru EMI and EGI indicators of 
the SEND verb, as follows, 
» any message sent with EMI is dispatched by BINS over the line with ETB or 
DLE ETB, thereby retaining -he turn 
» any message sent with EGI is dispatched by BTNS over the line with ETX or 
DLE ETX, signifying the end of the current transmission. 


In addition, physical block messages sent over the line must take into account 
the buffering capability of the receiving station, namely, 


e 512 characters 


The user application program, however, does not have to consider the actual size 
of the physical block because BINS automatically splits messages longer than the 
buffering capability by | 
- sending intermediate blocks of the message text with ETB or DLE ETB 
- sending the last block with ETB or ETX (DLE ETB or DLE ETX) according to 
whether EMI or EGI has been specified in the application programe 


Reception 


Enqueueing of blocks depends on the control character terminating it, namely, 
- if a block is received with ETB or DLE ETB, it is enqueued by BTNS with EMI 
. if a block is received with ETX or DLE ETX, it is enqueued by BINS with EGI. 


As a result, when the application program issues a RECEIVE, the ENDKEY field of 
the input CD of such a block would contain the following values, 

» 2 for EMI 

. 3 for EGI. 


See "Message Delimiters"’ in Section III. 
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Reverse Interrupt (RVI) 


RVI is a line procedure control message thru which a receiving station indicates 
to the sending station that : 


The 


the last block (sent with ETB or DLE ETB) has been correctly received 
transmission must be terminated as soon as possible for the following 
reasons, 

~ the receiving station cannot accept any more data 

- the receiving station requires the turn to transmit a message of a higher 


priority than the message it is currently receiving. 


RVI is handled as follows, 


reception of RVI : 


The actions taken by BINS when it receives an RVI while currently trans- 

mitting are, 

- the next block is transmitted with ETX or DLE ETX whatever the delimiter 
of the correspoding message is, ieee, EMI or EGI 

- the corresponding terminal queue from which the message was sent is set 
in the DISABLE OUTPUT state 

- a control message of the format ><CTLRVI is sent to the program queue to 
which the terminal is connected if the queue was declared with the BREAK 
option in the appropriate QUEUE command at CNC generation: 

- the line is set in the "input'' state in order to receive data from the 
Station which requested the turn to transmit. 


In order to detect RVI, the application program needs to check 

- either the DISABLE OUTPUT state of the terminal queue 

- or the contents of the program queue, namely, the ><CTLRVI control mes- 
sage is delivered to the application program as a null-length message 
with the a STATUS KEY value of "0", 


The detection of such an event may lead the application program to perform 
either action, 


‘- purge the terminal queue by sending to it the control message ><CTLPRG 


with EGI, only if the terminal queue was previously re-enabled, see below 
- restart the interrupted transmission by re-enabling the terminal queue 
with the ENABLE OUTPUT verb. 


sending RVI : 


If the L64 application program which is receiving messages wants to stop 
the sending Station, it has only to send into the corresponding terminal 
queue the control message ><CTLRVI. 


After the reception of every block ended with ETB, BINS checks the corres- 
ponding terminal queue to determine if the RVI has been requested by the 
receiving application program If so, the RVI request is sent immediately 
to the sending station. 
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Retaining the Communication 


As a default option, BTNS sends an EOT control character after the last block of 
a transfer specified with either ETX or DLE ETX. This mechanism returns the lini: 
to the control statee When in the control state, the line needs to be bidden for 
in order for a new transfer to take place. 


If several transfers are to be done in the same direction, the application pro- 
gram can specify that ECT must not be systen snnea a! sent by BINS by using the 
following control functions, 


The 


1. 


Te 


><KCO is specified with the first block of a transfer in order to inform 
BINS not to send EOT after the last blocks of the following transfers until 
a new transfer is initiated indicating a "break" 

><BCO is specified with the first block of the last transfer in order to 
inform BINS that after the last block of the current transfer it is to send 
EOT in order to "break" connection. 


sequence can be represented diagrammatically as follows, 


Transfer file 1 (><KCO specified in the first block) 


first block of file 1 intermediate blocks last block of file 1 


Transfer file 2 


first block of file 2 last block of file 2 


Transfer file n (><BCO specified in the first block). 


first block of file n last block fered eck transfer 
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CONTENTS OF USER MESSAGES 


The MCS COBOL user application may send and/or receive heading data alone or 
with message text. In either case, the heading character string, limited to 15 
characters, is located at the start of the message in the following format, 


Text 


Text contents depends on the mode of transmission, namely, 


» normal mode : 


There is no special format nor processing for the text except the proces- 
sing for standard marks according to the IM or OM options specified in 
appropriate linked terminal, see TERMNL command in Section V and the MTE 
operator command in Appendix F. 


- transparent mode : 


The application program receives transparent data as normal data except 
that no processing of standard marks is done whatever the IM option spe- 
cified for the linked terminal. 


To send in transparent mode, the user must enSure that each message is 
preceded by the standard mark ><UO06 in which case, the following actions 
are taken, 
- MCS does not process standard marks 
- BINS provides the appropriate control character sequences, e.g, 

DLE xxx, where xxx iS the control character specified in the text. 


><U06 must be provided with any message to be sent in transparent mode 
because it could be useful, in some cases, to send files with mixed nor- 
mal and transparent data, which is allowed by the BSC2780 line procedure. 


Subblocks 


Messages are split into subblocks in order to provide a more efficient means of 
error checking and retransmission of the subblock in error before the reception 
of the entire mesSage text. 


This capability for splitting messages into subblocks is at line protocol level 
and as such, is not visible to the application program. 
Instead, BINS and URP firmware enSure that the intermediate control characters 
Separating subblocks are handled as follows, for error detection and recovery, 
» checked for retries 
- inserted on emission 
» deleted on reception. 
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The format of the subblock separators depends on the mode of transmission, 


» normal mode 


text | ITB BCC SYN SYN text 


ce  / n 
subblock n a subblock n+1 
ynchronization 


block check character 


intermediate transmission block 


« transparent mode 


ci = TES SARE = oe a eel 
subblock n | subblock n+1 


estart transparent mode 
ynchronization 
lock check character 


intermediate transmission block 


The ability to use the subblock facility over a line is configured at URP firm- 
ware generation and is available in both modes of transmission, ieee, normal and 
transparente 


Message text is handled according to the direction of transmission, 


» on reception, sSubblock separators are deleted 


subblock a subblock 2 4 subblock n]|ETB/ETX 


qi Lestbp lock Separators 


subblock separators 


message sent 
over the line 


BINS and URP firm- 
ware control 


message in user 
buffer on RECEIVE 


subblock 1]subblock 2]subblock n| 


B-17 


BSC2780 LINE PROCEDURE 


- on emission, the following must be taken into consideration, 


- message blocks are split into subblocks according to the value given to 
the SBKLG parameter of the appropriate TERMNL command for the linked ter- 


minal, the default value being 80 


- the maximum number of subblocks for each message block is 16 


- a line configured without the subblock option at URP firmware generation 


cannot use the facility 


- even if the subblock option has been specified at URP firmware generation, 
the facility would not be of much use if the value defined for the SBKLG 
parameter is greater than any single block sent over the line because in 


this case, only 1 subblock per block is defined. 


text of 190 characters 
<> 


ue 


subblock 1 Ll subblock 2 - subblock 3]|ETB/ ETX 
| L-30 characters 
ubblock separators 


80 characters 


subblock separators 


80 characters 


message sent by 
application program 


BINS and URP firm- 
ware control 


message sent 
over the line 


TTY LINE PROCEDURE 


Terminals using the TTY line procedure have limited functionalities in that they 
have no specific control characters. Conmunication is performed thru a character 
by character mode over a point-to-point line with the L64 host computer. 


Messages seen by BINS contain, 
» message text 
- one trailer control character on input, in some cases. 


MESSAGE HANDLING ON INPUT 


On input, messages are terminated when any of the following control characters 
are received, namely, 


><CRV carriage return, automatically suppressed by the URP firmware and not 
received by BTNS 


><DC3 paper tape reader stop 


><EOT end-of-transmission, with the following considerations, 
- automatically suppressed by URP firmware and not received by BTNS 
- available only on terminals equipped with the "reverse channel" op- 
tion and connected over a 1200 bps line, ite, 


TN1200 
TWU/PRU1005 


><LFV line feed 


><SUB substitute, automatically suppressed by URP firmware and not received 
by BINS 


The following editing functions are, 


-» graphic \ = ASCII 5C, used to erase the previous character of the message 
text, if the LINE connecting the terminal has been de- 
clared with the ERCAP option 


- graphic @ = ASCII 40, used before ><CRV at the end-of-line to delete the 
complete line and hence no message is delivered to the 
application program. 


MESSAGE HANDLING ON OUTPUT 


On output, messages are terminated on exhaustion of the message length or are 
divided into fixed length blocks according to the following parameters declared 
in the TERMNL command, 

« BLOCKING 

« LLENGTH. 


The messages are edited by the application program before they are submitted to 
BTNS- 


TTY LINE PROCEDURE 


ERROR HANDLING 
A limited. error recovery capability is possible with terminals using the TTY 
line proceduree 


When the message "'RECV ERROR PLEASE REENTER" appears on the terminal, the oper- 
ator keys in the message text againe | 


Certain terminals replace invalid characters received from the host computer by 
a dedicated symbol, e.g., TWU/PRU1001 and TWU/PRU1003 use the graphic symbol 


Further recovery procedures must be supported by the application program. 
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TTY 
T™N300,1200 


The General Electric TermiNet is a printer with the optional features, 
» keyboard 
» Paper tape attachment 
» cassette 


The keyboard can send any of the 128 ISO codes. 


The character set for the printer comprises 94 graphic symbols (excluding the 
"Space') according to national options available. 
Characters received with parity error are treated as follows, 

- if TN300, an interrupt condition is set up at the terminal 

- if TN1200, the erroneous character is printed with the graphic symbol O. 


Line length depends on the model type and the options available, namely, 
- if TN300, 118 character positions 
- if TN1200, either 80 or 120 character positions. 


TERMINAL SPECIFICS 


Refer to respective product manuals. 
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TTY 


TN3OO, 


1200 


CONTROL CODES 


Unless specifically stated otherwise, the control code pertains to both TN300 
and TN1i200. 


><BEL 
><BSY 
><CRV 
><DC1 
><DC2 
><DC3 
><DC4 
><ESCO 
><ESC1 
><ESC2 
><ESC3 
>< ESC4 
>< ESCH 
><ESCJ 
><ESCK 
><ESCL 
><ESC: 
><ESC; 
><FFV 


><HTV 
><LFV 


><VTV 


sounds an alarm 

moves print one position to the left 

resets print position to first tabulation stop or leftmost column 
StartS paper tape reader forwards 

Starts paper tape punch 

Stops paper tape reader ) optionally used for cassette 
stops paper tape punch | 

starts paper tape reader backwards 

sets horizontal tabulation stop at current print position 

clears all tabulation stops 

applicable only for TN1200, selects red printing option 
applicable only for TN1200, selects black printing option 

turns on printer motor 

turns off printer motor 

turns on auxiliary device 

turns off auxiliary device 

resumes printing 

stops printing, allows transmission 


applicable only for TN1200, throws paper to top-of-page 
(option, fixed setting to 8, 85 or 11 inches) 


moves print to next tabulation stop or end-of-line 


advances paper depending on model type, 
- if TN300, one or two lines up (switch selectable) 
- if TN1200, one line up (switch selectable, 3 or 6 lines per inch) 


applicable only for TN1200, advances paper to next vertical tabulation 
stop or top-of-page 


TTY 
TWU/PRU1001, 1003, 1005 J 


The TWU/PRU1001, 1003, 1005 terminals are printers with the optional features, 
- keyboard 
» front feed mechanism for inserting single sheets 


Poe ae ke 2 — 


- paper loop for mechanically setting vertical tabulation and form length 


The character set for the printer consists of 63 graphic symbols, or 94, if the 
lower case option is present, according to national options available. 


The print line has a maximum capacity of 132 characters, or 80, as an option 
Characters received with a parity error are printed with the graphic symbol O. 


When the last column position in a line is passed, an automatic new iine move- 
ment occurs. In the case of the TWU/PRU1005, the new line movement can be suppressed. 


"Paper out'' condition leads to disconnection for a switched line 


CONTROL CODES 


><BEL sounds an alarm 

><BSV moves printer head one position to the left 

><CRV resets printer head to leftmost column or first tabulation stop 
><ESCO followed by page length character sets the page length for form feed 


><ESC1 sets a horizontal tabulation at current print position 
(10 positions to the inch, 16 tabulation stops maximum) 


><ESC2 clears all horizontal tabs (automatic on power-on) 


><ESC3 sets a vertical tabulation at current line count 
(6 lines to the inch, 10 tabulation stops maximum) 


><ESC4 clears all vertical tabs 


><FSV ejects single sheet, automatically performed when less than 1 inch 
from bottom of the sheet 


><GSV position single sheet to first print position, about half inch from 
top of the sheet 


><HTV moves printer head to next horizontal tabulation or end-of-line 
><LFV advances paper one line 


><VTV advances paper to next vertical tabulation or top-of-page 


6/79 
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TTY 
TWU/PRU1001, 1003, 1005 


TERMINAL SPECIFICS 


Refer to respective product manuals. 
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TTY 
TTY33,35,37,38 


The teletype printers have the optional features, 
» keyboard 


e paper 


tape attachment 


The keyboard can send either 96 or i128 IS0 codes, depending on the model. 


The character set for the printer comprises 63 graphic symbols, or 94 for the 


37 and 38 


models. 


Line length is either 72 or 86 characters. 


CONTROL CODES 


The applicability of the control codes depends on the model and installed op- 


tions. 


><BEL 
><BSV 
><CRV 
><DC1 
><DC2 
><DG3 
><DC4 
><ESC1 
><ESC2 
><ESC3 
><ESC4 
><ESC5 
><ESC6 
><ESC7 
><ESC8 
><ESC9 
><FFV 
><HTV 


><LFV 


rings a bell 

moves print position one character to the left 
resets print position to leftmost margin 

StartS paper tape reader 

Starts paper tape punch 

stops paper tape reader 

stops paper tape punch 

sets horizontal tabulation at current print position 
clears all horizontal tabulations 

selects printing in red 

selects printing in black 

sets vertical tabulation at line count 

clears all vertical tabulations 

rolls back paper one line 

rolls back paper half a line 

advances paper half a line 

advances paper to top-of-page (next page) 

moves print position to next tabulation stop on the same line 


advances paper one line (3 or 6 lines to the inch) 
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TTY 
TTY33,35,37,38 


TERMINAL SPECIFICS 


Refer to respective product manuals. 


TTY 
VIP7100 


The VIP7100 is a keyboard/display terminal. 


Entry of data in the display starts at the bottom line and on completion, the 
line is "rolled up'' if the new line function has been provided for; overwise, 
excess characters overprint the rightmost character position, i~e., position 80. 
The '"thome" position defines the leftmost character position of the bottom line. 
A cursor is displayed to facilitate data entry. 


Screen capacity is 12 lines of 80 characters. An option iS available for 24 


lines. 


The character set for the display consists of 63 graphic symbols, or 94, if the 
lower case option is presente 


The keyboard can send any of the 128 ISO codes, however, if only upper case is 


present, 


then the set is reduced to 94, 


To provide for automatic new line function, the parameter 


BLOCKING may be specified in the TERMNL command. 


CONTROL CODES 


><BEL 
><BSY¥ 
><CRYV 


><DC2 
><FFY 
><LFV 


sounds an alarm 
moves cursor one 


resets cursor at 
displayed on the 


moves the cursor 
resets cursor to 


"rolls up" lines 
tom line 


position to the left 


the left margin, without affecting characters already 
line 


one position to the right 
left margin for erasing the screen 


by one line in order to allow data entry in the bot- 


TTY 
VIP7100 


TERMINAL SPECIFICS 


Refer to respective product manual. 
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The VIP7200 is a keyboard/display terminal. 


Ly 
VIP7200 


A cursor is displayed to indicate the current entry position. The screen is 
filled from the top, progressing line by line to the bottom When the last line 
at the bottom is filled, the contents of the screen are automatically "roiled 
up" by one line in order to allow further data entry. 


Screen capacity is 24 lines of 80 characters. 


The character set for the display consists of 63 graphic symbols, or 94, if the 
lower case option is present. 


The keyboard can send any of the 128 ISO codes. 


CONTROL CODES 


><BEL 

><CRY 

><ESG3 
><ESC4 
><ESCA 
><ESCB 
><ESCC 
><ESCD 
><ESCH 


><ESCJ 
><ESCK 
><ESCY 


sounds an alarm 
resets the cursor at left margin on the same line 
sets normal intensity for screen illumination 


sets low intensity for screen illumination 


moves cursor one line up but at the same character position 


moves cursor one line down but at the same character position 


moves cursor one character position to the right on 


the same line 


moves cursor one character position to the left on the same line 


resets cursor in "home'' position, iee., at leftmost 
at the top of the screen 


erases text display from current cursor position to 
erases text display from current cursor position to 


resets terminal to initial state, as follows, 
e screen erased 

« cursor in "home" position 

- normal intensity for screen illumination 


The equivalent control sequence is ><ESC><C79 


><ESCF position the cursor according to character position 


><ESCL 


><ESCH 


><LFV 


sends data from start of line or page, depending on 
to the current cursor position 


causes the terminal to indicate its cursor position 
format given in ><ESCf 


moves cursor one line down; if the cursor is on the 
up" will occur 
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character position 


the end-of-page 


the end-of-line 


and line number 


switch setting, 


according to the 


bottom line, "roll 


TTY 
VIP7200 


To position the cursor, proceed as follows, 


. refer to page 4-31 "Mark Representation" for determining the values 
to be given to 
-~ character position 
- line number 


send the control sequence of the format 


><ESC£ followed by character position, then line number 


TERMINAL SPECIFICS 


Refer to respective product manual. 
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VIP LINE PROCEDURE 


MESSAGE FORMAT AS SEEN BY BTNS 


A text message exchanged between BINS message processing routines and the SURP 
firmware has the following format : 


STI station index byte, ise, the station address as specified in the STATN 
command at CNC generation 


SOH start-of-header 
EBCDIC value O1 


ADR terminal address as specified in the :TERMNL command at CNC generation 


STA status code 
STA =EBCDIC OO=NUL, for text only 
STA =EBCDIC 3F =PRT, for print message text 
see text following for individual terminals 


FC1 function-code-1, see text following for individual terminals 
FC2 function-code-2, see text following for individual terminals 


STX start-of-text 
EBCDIC value 02 


ETB end-of-transmission-block, only used for loading BTT7300 
EBCDIC value 26 


ETX end-of-tex 
EBCDIC value 03 


EOT end-of-transmission 
EBCDIC value 37 


VIP Headers 


The header of each message sent to or from a VIP terminal contains 3 bytes of 
information which may be useful to the MCS COBOL program 

These 3 bytes are STA, FC1 and FC2. BINS has no effect on FC1 and FC2. Both 
function codes are unedited either on input or output. SURP firmware uses the 
TCT (terminal control table) for transcoding them 


The VIP header is visible to the program when one of the following is fulfilled, 
« the TERMNL command is specified with either IM=MK or IM=UN 
« the network command MTE specifying the terminal and either IMARK or INEDT is 
keyed in 
« the terminal operator command $*§MTE specifying either IMARK or INEDT is 
keyed in. 


The control code received by the program when the above conditions are met, is 
of the format ><UO3abc, see Section IV. 
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VIP LINE PROCEDURE 


The values a, b and c are sent from the VIP terminal, where, 
» a represents the status code 
« b represents the first function code 
e c represents the second function code, 


The user can also include message headers of the same format in output messageSe 
These headers can be included in any output mode. 


For the values of VIP header characters, see text following for individual termi- 
nals as well as their respective product manuals. 


VIP Message Trailers 


Terminals of the VIP line procedure use the sequence ><ETX><EOT to denote mes- 
sage termination, 


Some terminals are equipped with ETX and EOT keys which when pressed generate the 
appropriate control code. 


VIP Erasing Functions 


VIP terminals are buffered. All editing and erasing functions can be performed 
locally before entering a transmission request. 

Trailing blanks are suppressed from transmitted messages. Most VIP terminals do 
not transmit empty mesSages. 


When coding application programs, the user should disregard empty messages. 


VIP Terminals 


Type Model 


TWU/PRU1901 TWU/PRU1901 VIP7700 | VIP7700R 


VIP7700 


VIP765 VIP765 VIP7705 


VIP775 VIP775 
VIP785 VIP785 VIP7760 | VIP7760 


6/79 
B-32 AQ53-01A 


VIP 
TWU/PRU1901 


The TWU/PRU1901 is equipped with a keyboard and printer with a buffer capacity of 
960 characters. 95 different graphic symbols can be printed, basically the full 
ISO ASCII set, with variations depending on national keyboard options. 

Its visibility to the host computer is that of a VIP7700 terminal with limited 
functionalities. 


TWU/PRU1901 KEYBOARD/PRINTER 


The page is organized according to parameters entered either by the operator or 
from the application program. 


Printer and medium specifications are, 
+ a page is composed of from 10 to 90 lines 
- a line contains from 38 to 132 characters, default value is 132 characters 
«+ paper width varies from 4'' (10 cms) to 15" (38 cms) 
e characters are 10 to the inch 
» lines are 6 to the inch 
.» the minimum margin between the sprocket hole and the first character is 4" 
(measured from center-to-center). 


Data entered on the keyboard is placed in a buffer, where editing can be carried 
out by the operator before the data is transferred to the host computer. 


Header for Keyboard/Printer 


The 3 parameters in the VIP header have the following specifications, 
« STA=EBCDIC 3F, when sent by the terminal, as forced by BINS 
=EBCDIC 00, as received by the application program 
- FCl1=received as sent by the application or overridden by the operator 
» FC2="¥", when the last character sent has been printed on fanfold paper 
="I', when the last character has been printed on single forms 


Control Codes 


><BO1 new page function, form feed , 
><BO3 new line function 

><CRV><LFV see ><BO3 

><DC3 set page dimensions according to number of lines and characters/line 
><ESC1 set horizontal tabulation, up to 10 tab stops may be set in the line 
><ESC2 clear all horizontal tabulation stops 

><ESC5 set vertical tabulation, up to 10 tab stops may be set in a page 
><ESC6 clear all vertical tabulation stops 

><FFV see ><BO3 

><G2F sound a short acoustic signal 


><HTV move print head to next horizontal tab stop, end-of-line is tab stop 
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VIP 
TWU/PRU1901 


><NLY see ><BO3 


><VTY skip paper to next vertical tab stop, top-of-form is tab stop 


To set page dimensions, a sequence is made up of ><DC3 followed by the number of 
lines in the form and the number of characters per line. To define the respective 
numbers required, refer to "ASCII Code for Control Characters & Graphic Symbols" 
on page 4-32, and proceed as follows, 
e for choosing the number of lines from 10 to 90, subtract 9 from the number of 
lines required, eg, if 55 lines are required, then the significant value to 
be defined is (55-9) = 46 
- fer choosing the number of characters per line from 38 to 132, subtract 37 
from the number of characters required, e.ge, if 80 characters are required, 
then the significant value to be defined is (80-37)= 43 
- to define the values as graphic symbols or their EBCDIC equivalents, proceed 
as follows, 
- start from the ASCII code 20 which is a "Space" 
- count aS many codes as defined by the "significant value" from the ASCII 
code 20 
- the ASCII code arrived at defines the number required, eeg.e, for the 
"significant value" of 46, the corresponding graphic symbol is M 
- the control Sequence to send to set the page to 55 lines of 80 characters per 
line is ><DC3MK. 


TWU/PRU1901 FRONT FEED 


When the option is present, single sheets may be inserted from the front between 
the guides independent of the tractor mechanism. 


Printer and medium specifications are, 
- the vertical print area is 9 less than the number of lines defined for the 
sheet 
» the number of characters per line is set at 40, 48, 72 or 80 


The header for the normal traction printer on the previous page applies to the 
"front feed" printer. 


Control Codes 


The control codes listed: for the normal traction printer on the previous page ap- 
ply to the "front feed'' printer. Additional control codes are, 


><DC2 applicable following paper movement, ><BO1, ><FFV, ><LFY, ><VTV 


><ESC3 select single sheet for printing and move head to first print position 
on Single sheet 


><ESC4 select fanfold for printing and move head to first print position on 
fanfold. 
This is the selection by default at "power on" and is resorted to after 
ejection of the single sheet by "form feed" or excessive paper skips. 


VIP 
VIP765 ,775, 785 


The VIP765, VIP775 and VIP785 are terminals which have a display and keyboard, 
and are programmed in a similar manner as the VIP7700, with limitations to be 
found in their respective product manuals. 


PRINTER ATTACHED TO VIP765/775/785 


The printer is NOT defined by a TERMNL command. Print functions are managed by 
the application program thru the status of the VIP header. 


On the terminal side, the operator can request the application to edit the trans- 
mitted message and its printed version by sending the message with the "print" 
key instead of the "transmit'' keys This action results in the PRT status of the 
VIP header. 


Header for Printer 


The 3 parameters in the VIP header have the following specifications, 
» STA=EBCDIC 3F, denoting PRT status for the printer 
=EBCDIC 00, if there are no print requests 
« FCi=last function code entered on the keyboard or echo to the program 
- FC2=last but one function code or echo to the program 
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VIP 
VIP765,775,785 


TERMINAL SPECIFICS 


Refer to respective product manuals. 


B- 36 


VIP 
VIP7700 


VIP7700 DISPLAY/ KEYBOARD 


The screen is organized in 12 or 24 lines of 80 character positions. An option 
is available for 22 lines of 46 characters. Including the "space", 64 different 
graphic symbols, (or, 95 with the lower case option) can be displayed. The types 
of graphic symbols depend on national keyboard options. An entry marker is dis- 
played as an aid in formatting the Screen. 


Header for Display/Keyboard 


The 3 parameters in the VIP header have the following specifications, 
- STA = EBCDIC OO = COBOL Collating Sequence 1 
- FCi = last function code entered on the keyboard or echo to the program 
« FC2 = last but one function code entered or echo to the program. 


II 


Text for Display 


BLANKING : 
><CA1 displayed as a "space" or graphic ™ starts a character string which is 
blanked out on display. 
A "space" or the end-of-line ends the blanking. 
BLINKING : 
><BEL or ><BLK or graphic 7 are displayed as graphic ~ and starts a blinking 
character stringe 
A "space" or the end-of-line ends the blinking string. 
COBOL : 
LINE and PAGE keywords have the same effect as ><BO3 and ><BO1 respective- 
ly, when used in a Sentence with the SEND verb. 
ENTRY MARKER : 


The following terminal control codes in mark form alter the current entry 
position, 


><BO1 as for ><DC4, with display memory cleared, ieee, screen erased 
><BO3 equivalent to the sequence ><CRV><LFV 

><BSV same line, 1 character position to the left 

><CRV same line, leftmost character position 

><DC1 one line up, same character position, iee., reverse line feed 
><DC2 same Lind; 1 character position to the right, ieee, forward space 
><DC3 position cursor according to line number and character position 
><DC4 uppermost line, leftmost character position, ieee, page return 


><DEL follows ><HTV, ><FFV, ><BOl1 as a "time fill" 
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VIP 
VIP7700 


><FFV same as ><BO1 
><HTV same line, ist. tabulation to the right 
><LFV one line down, same character position 


><NLV same as ><BO3 


To position the cursor, see page 4-31 "Mark Representation" 


FORMS MODE : 


The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. Forms are defined while in normal mode. 


><ESCM enters the terminal into forms mode 
><ESCN resets the terminal into normal mode 


><FSV file separator, followed by a displayable character, begins a fixed 
field 


><GSV group separator, begins a variable field followed by a parameter 


values of variable field parameter: 

O the field may contain a displayable character to be transmitted and 
printed 

1 printing of the displayable character is to be suppressed 

2 transmission of the displayable character is to be suppressed 


After the forms definition is completed, the terminal is entered into 
forms mode to allow protected operation under forms control. 
MESSAGE BOUNDARIES : 


In normal mode, message boundaries can be controlled by the application pro- 
gram using the following terminal control codes, 


><ESCT start of message boundary 
><ESCU end of message boundary 


PAGE OVERFLOW : 


detection 
ERROR indicator on the terminal illuminates. 


cause 
» result of program error 
» result of an operator error in failing to clear the screen 


correction 

« press CTR and CLEAR control keys simultaneously 

» send the command $*$RDY 

- if. overflow occurs again as a result cf message length, send the command 
S*SRDY STRONG to cancel the message. 
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VIP 
VIP7700 


TABULATION : 
The following terminal control codes in mark form set the tabulation, 
><ESCI sets the tab stop at the current entry marker position 


><ESC2 resets all the tab stops 


VIP7700 CASSETTE UNIT 
The VIP7700 cassette unit must be defined by a separate TERMNL command specify- 
ing STYPE=CAS. 


Messages with status 00 (STA=00) in the VIP header can be exchanged between the 
application and the cassette unit. 
Messages sent to the cassette unit must contain the following information, 

- selection of the cassette unit 

e type of command 

» message text, where applicable. 


[he keyboard remains locked during a cassette operation. 


Any text sent to the cassette is displayed on the screen. In order to avoid page 
overflow, the programmer should systematically prefix the text with ><FF, which 
clears the screen and which will not be recorded in the data block. 


After a read command, the application has to issue a RECEIVE to the program queue 
to which the cassette unit is assigned in order to receive the block that was 
read. In blocks read from a cassette, the FC1 and FC2 parameters in the VIP head- 


er have the values at the time when the page was recorded, 
SELECTION : 

><ESCE selects unit 1 

><ESCF selects unit 2 


COMMAND : 
><ESCD backspace a page with no text following 
><ESCP rewind to start of cassette tape 
><ESCR read a page with no text following 


><ESCS write a page followed by text to maximum display size of 1920 charac- 
ters; if no text follows, the contents of the display memory will be 
recorded instead 


Problem : To write "message text'' to cassette unit 1 


Solution : Send the following message 


><ESCE><ESCS'message text" 
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VIP 


VIP7700 


BLANK CASSETTE BLOCK : 


Because of compression of trailing spaces by the VIP7700 controller, a cas- 
sette data block filled with spaces is transfomed into an empty message 
which is not delivered to the program queue in normal mode. 


In mark mode (IM=MK) a mesSage containing only ><ETX><EOT is received by 
the program 


VIP7700 PRINTER 


Printable text is defined between the start-of-te t and the end-of-text, which 
can be denoted by ><EMV. Text output to the printer does not appear on the 
screens The three ways of addressing the printer are treated as follows : 


Method I : 


Method 2 : 


Method 3 : 


Address the display/keyboard with STA=3F in the VIP header. 


The display/keyboard is locked during printing. 

The message is printed as it ise The text in the message must contain 
any necessary format control codes, see "Text for Display", and any 
other control codes specific to the printer. 

"Time fill" control codes may be needed for proper mechanical synchro- 
nization. Full line size capability can be obtained by this method. 


- Define the printer by a separate TERMNL command specifying STYPE=PRT 
- Address the display/keyboard with STA=00O in the VIP header. 


The keyboard is not locked and may be used for ey into the screen 
and transmitted while printing proceeds. 

Data is printed according to the standard VIP7700 hard copy format 
with a maximum line length of 80 characters. Print format controls, 
such aS carriage return and line feed are generated automatically by 
the terminal controller. 


- Define the printer by a separate TERMNL command specifying STYPE=PRT 
« Address the display/keyboard with STA=3F in the VIP header. 


The keyboard is not locked and may be used for entry into the screen 
and transmitted while printing proceeds. 

The message is printed as it ise The text in the message must contain 
any necessary format control codes, see '"'Text for Display", and any 
other control codes specific to the printer. 

"Time fill" control codes may be needed for proper mechanical synchro- 
nizations Full line size capability can be obtained by this method. 
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VIP 
VIP7760 


VIP7760 DISPLAY/ KEYBOARD 


The screen is organized in 12 or 24 lines of 80 characters. Including the "space" 
95 different graphic symbols (basically ISO/ASCII set with national options) can 


be displayed. An entry marker is displayed as an aid in formatting the screen 


Text fcr Display 


The control sequences for tabulation, entry marker control and message boundaries 
are the same as for the VIP7700. Blinking and blanking may be supported as op- 
tions. 


FORMS MODE : 


The following terminal control codes in mark form set the terminal either in 
forms mode or in normal mode. Forms are defined while in normal mode. 


><ESCM enters the terminal into forms mode 

><ESGN resets the terminal into normal mode 

><FSV defines the start of a fixed field 

><GSV defines the start of a variable field, followed by a parameter 


values of variable field parameter: 
O the field is right-justified, non-repeated and alphanumeric to be 
transmitted and printed 


1 inhibits printing 

2 inhibits transmission 

4 numeric only field 

8 indicates a number of a line field to be repeated 
16 the field is left-justified 


><RSV terminates a repetitive line field, followed by a repetition code 


value of repetition code: add 64 to the number of times that the line 
field is to be repeated 


For integer-to-graphic conversion, see 


« ASCII Code for Control Characters & Graphic Symbols, page 4-32 
- EBCDIC Character Set & COBOL Collating Sequence, page 4-05 


VIP7760 DISKETTE 


The VIP7760 diskette is not supported on-line. 


B-41 


VIP 
VIP7760 


VIP7760 PRINTER 


The printer must be defined by a separate TERMNL command specifying STYPE=PRT. 
Text for printing can only be sent to the printer address. The three printing 
modes are treated as follows : 


TRANSPARENT MODE : 


Method of addressing : Either 
» address the printer with STA=3F in the VIP header 
Or 
» address the printer with STA=O0O in the VIP header 
-e precede the text with ><ESCZ. 


The message is printed as it is. The text in the message must contain any 
necessary format control codes, see "Text for Display", and any other con- 
trol codes specific to the printer. 

"Time fill" control codes for the proper mechanical synchronization of the 
printer should also be included in the message text. 

><USV followed by a count can be used as a "time fill'. To define the. 
count, refer to "ASCII Code for Control Characters & Graphic Symbols" on 
page 4-32, and proceed as follows, 

« Start from ASCII code 20 which is a "space" 

« count aS many codes as "time fills" required from ASCII code 20 

- the ASCII code arrived at defines the "time fill" count 

« use either the graphic symbol or the EBCDIC equivalent of the code. 


DISPLAY IMAGE MODE : 


Method of addressing : - address the printer with STA=00 in the VIP header 
- end the message text with ><ESCN. 


The message text may optionally begin with ><ESCX or ><ESCY. The text is 
formatted automatically on the printer according to the display format char- 
acteristics. Printer control functions and "time fills'' are generated auto- 
matically by the VIP7760 system 


FORMS MODE : 


Method of addressing : « address the printer with STA=00O in the VIP header 
- end the message text with ><ESCM, 


If the message text begins with ><ESCX, only variable fields are printed. 


If the message text begins with ><ESCY, both fixed and variable fields are 
printed. 


The printer is controlled automatically by the VIP7760 system Text which is 
not preceded by either ><ESCX or ><ESCY is not printed. Variable fields 
defined as "inhibit printing" will not be printed. 
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APPENDIX C 


Error messages output after the execution of the H_CNC utility are, 
- NDL error messages which are written to the SYSOUT file 
- JOR (job occurrence report) error messages. 


Error messages output after the execution of the H_QMAINT utility appear in the 
job occurrence report and are listed under 
« QMAINT error messages. 


NDL and QMAINT ERROR MESSAGES 


Both types of error messages have the same format, namely, 


ERROR Fe | SEVERITY (Ss) error-mesSage-text 


- CN denotes that the source is H_CNC utility 
« QC denotes that the source is H QMAINT utility 


» nnnn denotes the message number 
« s denotes the severity of the error as follows, 
- 2: warning, CNC generation may still be usable 
- 3: fatal, leading to a CNC abort but allows a complete syntax analysis of 
the network description 

- 4: fatal, leading to a CNC abort and may stop command analysis. 

* error-message-text denotes the error condition and may be accompanied by 
the contents of the Rc register of the following format : 
RG = XXXXXXXXPYYYYVYVYY 5 ZZZZZ2Z22Z 
- XXxxxxxx : the hexadecimal contents of the RC register 
- yyyyyyyy : the name of the procedure, SIU (system integration unit) 
- Z2zz2z2zz2z : the return code 


JOR ERROR MESSAGES 


The format of the message is: KXmmerror-message-text 


- XXnn denotes a 2-alpha character code followed by a 2-digit number 
* error-message-text denotes the error condition and may be accompanied by 
the contents of the RC register of the format given above. 


The 2-alpha character code preceding the messages indicates their source, namely, 
« CC messages are from BINS 

» CN messages are from CNC 

» QC messages are from MCS COBOL application. 


RETURN CODES 


The list of return codes are those set by MAM. For GCOS return codes, refer to 
JCL User Guide Manual. 


NDL ERROR MESSAGES 


0000 - 0004 


e ERROR CN{0000] 


e ERROR CN{0001] 


e ERROR CN[0002] 


e ERROR CN{0003 


e ERROR CN[0004] 


SEVERITY ()ILLEGAL SYNTAX 


syntax : t denotes the element in error. 
cause : . wrong command name, keyword or argument. 
- missing or duplicated positional parameter, ieee, 
name, LNnn, station-index, TYPE and STYPE. 
- misplaced GENCOM command. 
- violation of CNC reserved syntax, see Appendix E. 
action : correct the command and rerun H_CNC utility. 


SEVERITY (3)NO QUEUE FOR TERMINAL : terminal-name 


syntax : "terminal-name" appears in the appropriate TERMNL 
command. 

cause : no terminal queue has been declared for the terminal 
having output capability and dedicated to a program 
queue (ASSIGN). 

action : insert a QUEUE command bearing the "terminal-name"' 
and other relevant parameters for the queue declared, 
and rerun the H_CNC utility. 


SEVERITY @) SEVERAL TERMNL FOR A TTY LINE 


Syntax : as denoted 

cause : only 1 TERMNL command is allowed after a TTY LINE 
command. 

action : remove superfluous TERMNL commands and rerun H_CNC 
utility. 


SEVERITY (3) DUPLICATED : name 


Syntax : "name!'' can be that of the DCTAP, GENCOM, LINE, QUEUE, 
STATN and TERMNL commands. 

cause : "names'' declared for the commands listed above must be 
unique for a network; the only allowed duplication is 
the terminal-name and its associated terminal-queue- 
name. 

action : substitute "name" indicated in the appropriate command 
and rerun H_CNC utility. 


SEVERITY G) INVALID NAME LENGTH : name 


Syntax : "name'' can be that of the DCTAP, GENCOM, LINE, QUEUE, 
STATN and TERMNL commands. 

cause : '"mames'' declared for the commands listed above must be 
limited to a maximum of 4 alphanumeric characters; 
only "password" defined by the KEY parameter of the 
GENGOM command may comprise up to 10 alphanumeric 
characterSe 

action : correct "name'"' indicated in the appropriate command 
and rerun H_CNC utility. 


ERROR 


ERROR 


ERROR 


ERROR 


ERROR 


ERROR 


ERROR 


NDL ERROR MESSAGES 
0005 - 0011 


cn{0005] SEVERITY (@)QCPOOL NOT DEFINED BY GENCOM 


cn [0006 | 


CN 


cn [0005] 


cn 


on [5070] 


oN 


syntax : as denoted 

cause : a queue has been declared with a QCPOOL option in the 
appropriate QUEUE command while a QCPOOL option has 
not been specified in the GENCOM command. 

action : insert the QCPOOL option in the GENCOM command and 
rerun H_CNC utility. 


SEVERITY (@)STATN NOT ALLOWED ON A TTY LINE 


syntax : as denoted 

cause : as denoted 

action : remove the STATN command following all TTY LINE 
commands and rerun H_CNC utility. 


SEVERITY G) MAMNB DECLARED BY GENCOM WHILE NO QUEUE DECLARED 


Syntax : as denoted 

cause : the GENCOM command declares a number of MCS program 
simultaneities while no queue has been declared. 

action : insert appropriate QUEUE command(s) or remove MAMNB 
from GENCOM command and rerun H_CNC utility. 


SEVERITY) INVALID VALUE : value 


Syntax : '"value'! indicated appears against the parameter of 
the command in error. 

cause : ''value'' is outside of the range allowed by the 
appropriate command. 

action : correct the value for the parameter in the appropriate 
command and rerun H_CNC utility. 


SEVERITY(3) MISSING STATN OR TERMNL 


Syntax : as denoted 
cause : a LINE command must be followed by one of either, 
» STATN if it describes a multipoint or polled line 
- TERMNL if it describes a TTY line 
action : insert the appropriate command and rerun H_CNC utility. 


SEVERITY (2)ONLY TERMINAL QUEUES DECLARED 


Syntax : as denoted 

cause : message switching only thru terminal queues is allowed 
because no program queues have been declared. 

action : none 


SEVERITY ()MISSING LINE OR STATN 


syntax : as denoted 

cause : a TERMNL command must immediately follow one of either, 
- a TTY LINE command 
- a STATN command for all other line procedures. 

action : insert the appropriate command and rerun H_CNC utility. 
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NDL ERROR MESSAGES 
0012 - 0017 


e ERROR CN[0012] SEVERITY(3) DUPLICATED KEYWORD 


Syntax : as denoted 
cause : a keyword has occurred more than once in a command. 
action : correct the command and rerun H_ CNC utility. 


e ERROR CN[0013] SEVERITY(4)UNABLE TO CREATE : name 
RG = XXXXXXXXPYYVYYVYYY >» ZZZZZZZzZ 


Syntax : 'name'' can be that of a table, buffer or work segment. 
the contents of G4 specifies the reason for the abort. 
cause : a system malfunction has prevented CNC from creating 
the table, buffer or work segment identified. 
action 1 :if zzzzzzzz—=NEXPDERR, use the OCL command CMM to can- 
cel VCAM or MAM, and then retry the job step. 


action 2 :if the same error persists, or if zzzzzzzz is not 
NEXPDERR, then call the field engineering service. 


ERROR CN[0014] SEVERITY(@)MISSING GENCOM 


Syntax : as denoted 

cause : the GENCOM command must be present and must head the 
list of NDL commands. 

action : insert the GENCOM command or correct the sequence of 
NDL commands, if the GENCOM command is present, and 
rerun H_CNC utility. 


e ERROR CN{0015] SEVERITY@)LINE NOT DEFINED OR CONNECTED TO SRST 


Syntax : as denoted 

cause : the name "'LNnn'"' of a LINE command is not present in 
the SRST or is not available. 

action : call field engineering service. 


e ERROR CN[0016] SEVERITY@)LINE RESERVED FOR SYSTEM CONSOLE 


Syntax : as denoted 

cause : the name of a LINE command is of the type CSP in the 
SRST and denotes the line exclusively reserved for the 
system console. 

action : correct the command and rerun H_ CNC utility. 


ERROR GN{0017 SEVERITY (3) NO MASTER TERMINAL DECLARED 


Syntax : as denoted 

cauSe : a TERMNL command specified as TYPE=SLAVE follows 
immediately a LINE or STATN command. 

action : insert a TERMNL command for a '"master'' terminal before 
the TERMNL command for a "'slave'' terminal and rerun 
H_CNC utility. 


e ERROR CN[0018] 


e ERROR CN{0019 


e ERROR CN([0020] 


e ERROR CN[0021] 


e ERROR CN[0022] 


NDL ERROR MESSAGES 
0018 - 0022 


SEVERITY (3)NOT A QUEUE OR TAP NAME : name 


Syntax : 'name'' is the argument specified for the ASSIGN 
parameter of a TERMNL command. 
cause : the 'name'' does not match any of the following, 
e program queue as declared by a QUEUE command 
- VCAM subsystem, ieee, IOF or TDS, as declared 
by the DCTAP command. 
action : correct the command and rerun H_CNC utility. 


SEVERITY(@) POLLIST GREATER THAN DECLARED IN SRST 


syntax : as denoted 

cause :;: the value declared for the POLLIST parameter of a 
LINE command defines more station index entries than 
those reserved in the URP for that line. 
(rf. POLLISTLENGTH parameter of SRST entry) 

action : reduce the number of station index entries in the 
appropriate LINE command and rerun H_CNC utility. 


SEVERITY (4) SEGMENT TOO LARGE : name | 


Syntax : '"name'' identifies one of the following, 
- the BINS buffer pool 
- the VCAM buffer pool 
- core queues 

cause : the value(s) declared for any of the above parameters 
has exceeded the allowable limit. 

action : adjust the size of the parameter(s) in either the 
GENCOM or the QUEUE command and rerun H_CNC utility. 


SEVERITY (4) UNABLE TO ACCESS SYSIN 
RG = XXXXXXXX#YYYYYYVYY 5 ZZZZZZ2Z 


syntax : the contents of G4 specifies the reason for the abort. 

cause : system error 

action : check JCL statements and retry the job : if the same 
condition occurs, then call the field engineering 
service. 


SEVERITY (2) ONLY PROGRAM QUEUES DECLARED 


syntax : as denoted 

cause : MCS applications can only perform data collection 
because no distribution capability in the form of 
terminal queues has been specified. 

action ;: none 


NDL ERROR MESSAGES 


0023 - 0026 


e ERROR cN[0023] 


e ERROR CN[0024] 


e ERROR cN[0025| 


e ERROR CN 


SEVERITY G)QUEUES FILE ACCESS ERROR : 
RC = XxxxXxXXPyyYyyYYYY, ZZZZZZZZ 


Syntax : the contents of RC specifies the error and the system 
primitive. 
cause : the error when accessing a queues files can be one of 
either, 
» a user error, ieee, file not preallocated 
» a system error (IOFAIL). 
action: . if file is not preallocated, then correct as 
appropriate and retry the job. 
» if IOFAIL, retry the job : if the same condition 
occurs, then call field engineering service. 


SEVERITY (@)NON STANDARD DISK 


Syntax : as denoted 

cause : the disk queues file is preallocated on a device other 
than MS/M300, 350, 400 or 402. 

action : correct the appropriate JCL statement and retry the 
job. _ 


SEVERITY ()QUEUES FILE TOO LARGE 


Syntax : as denoted 

cause : the size of preallocated disk queues file has exceeded 
the allowable limit. 

action : adjust the file size in the appropriate QUEUE command 
and rerun H_CNC utility. 
(see Section V "Tuning the Network") 


SEVERITY (3) PARAMETERS CONFLICT : text 


syntax : "'text'!' defines conflicts between parameters of the 
same or different commands. 


BKMOD/LINE TYPE 

action : check BKMOD parameter of the LINE command pertains to 
TTY terminals equipped with the BREAK key. 
correct the appropriate LINE command and rerun H_CNC 
utility. 


CLV/LINE TYPE 

action : check that the value 3, ieee, 5 bit code, has not been 
specified for CLV for a synchronous line procedure. 
correct the appropriate LINE command and rerun H_CNC 
utility. 


CORE QUEUE/ RESTART 
action : check RESTART parameter of the QUEUE command is not 
specified for core queues which are defined by, 
« the QCBLKSZ and QCPOOL parameters of the GENCOM 
command 
» the NUMBLK parameter of the QUEUE command. 


correct the relevant command(s) and rerun H_CNC utility. 


C-06 


( 


e ERROR CN 


NDL ERROR MESSAGES 
0026 


SEVERITY (3) PARAMETERS CONFLICT : text 


syntax : "text'' defines conflicts between parameters of the 
same or different commands. 


EPX/LINE TYPE 

action : check EPX parameter of the LINE command pertains only 
to TTY37 type terminals which allow echoplex. 
correct the appropriate LINE command and rerun H CNC 
utility. 7 


ERCAP/LINE TYPE 

action : check ERCAP parameter of the LINE command pertains 
only to TTY terminals which have "erase!'' capability. 
correct the appropriate LINE command and rerun H_CNC 
utility. 


ININS/LINE TYPE 

action : check ININS parameter of the LINE command pertains 
only to synchronous line procedures which require 
"synchronization". 
correct the appropriate LINE command and rerun H_CNC 
utility. 


LINPLG/LINE TYPE 
action : check LINPLG parameter of the LINE command has not 
been specified for a TTY line pracedure. 
correct the appropriate LINE command and rerun H_CNC 
utility. 


NAUCDE/ LINE TYPE 

action : check NAUCDE parameter of the LINE command pertains 
only to a "switched" line and has not been specified 
for a line having 108/2 CCITT interface 
correct the appropriate LINE command and rerun H_CNC 
utility. 


OPERATOR/ CLOSE 

cause : the network control terminal identified as OPER in the 
appropriate TERMNL command has been declared as a 
member of a LINE or STATN specified with the CLOSE 
option. 

action : correct the appropriate TERMNL command and rerun H_CNC 
utility. 


OPERATOR/LINE TYPE 

cause : the network control terminal identified as OPER in the 
appropriate TERMNL command is connected over a 
"switched" line. 

action : correct the appropriate TERMNL command and rerun H_CNC 
utility. 


NDL ERROR MESSAGES 


0026 


e ERROR CN 


SEVERITY (3) PARAMETERS CONFLICT : text 


Syntax : "text!'' defines conflicts between parameters of the 
Same or different commands. 

OPERATOR/ SLAVE 

cause : the network control terminal identified as OPER in the 


appropriate TERMNL command has been declared SLAVE. 
action : correct the appropriate TERMNL command and rerun H_CNC. 


OPERATOR/TYPE, STYPE 

cause : the network control terminal identified as OPER in the 
appropriate TERMNL command has been specified with 
TYPE and STYPE contradictory to network control 
function. 
- TYPE must be other than © 

HL62, HL64 and HL66. 

- STYPE must only be KCT or KPR. 

action : correct the appropriate TERMNL command and rerun H_CNG. 


POLLIST/LINE TYPE 

action : check POLLIST parameter of the LINE command has been 
specified for a "multipoint" line and has not been 
used for a TTY line procedure. 
correct the appropriate LINE command and rerun H_CNC. 


PROG. QUEUE/CTLRST 
cause : only disk terminals can be declared with CTLRST option. 
action : correct the appropriate QUEUE command and rerun H_CNC. 


RESTART/ CTLRST 

cause : a disk queue cannot be declared with both CTLRST and 
RESTART options. 

action : correct the appropriate QUEUE command and rerun H_CNC. 


SLAVE/ASSIGN 

cause : a terminal declared SLAVE in the TERMNL command must 
immediately follow a "master" terminal. 

action : correct the appropriate TERMNL command, or insert a 
"master'' TERMNL command before the command in 
question, or check the NDL command sequence and rerun 
H_CNC utility. 


SLAVE/ AUTO 

action : check AUTO parameter of the TERMNL command pertains 
only to a "receive-only' or "master" terminal, and not 
to a terminal declared SLAVE. 
correct the appropriate TERMNL command and rerun H_CNC, 


SLAVE/ CONTROL 

action : check CONTROL parameter of the TERMNL command has not 
been specified for a terminal declared SLAVE. 
correct the appropriate TERMNL command and rerun H_ CNC, 


C-08 


e@ ERROR CN{0026 


NDL ERROR MESSAGES 
: 0026 


SEVERITY (3) PARAMETERS CONFLICT : text 


Syntax : "text'! defines conflicts between parameters of the 
same or different commands. 


SPEED/LINE TYPE 

action : check SPEED parameter of the LINE command has not been 
specified for a synchronous line procedure. 
correct the appropriate LINE command and rerun H_CNC. 


SPN/LINE TYPE 

action : check SPN parameter of the LINE command pertains only 
to an asynchronous line procedure. 
correct the appropriate LINE command and rerun H_CNC 


TERM. QUEUE/ BREAK 
cause : the BREAK parameter of the QUEUE command pertains only 


to program queueSe 
action : correct the appropriate QUEUE command and rerun H_CNG. 


TERM. QUEUE/ SHARE 

cause : the SHARE parameter of the QUEUE command pertains only 
to program queues. 

action : correct the appropriate QUEUE command and rerun H_CNG 
utility. 


TERM. QUEUE/TWA 

cause : the TWA parameter of the QUEUE command pertains only 
to program queues. 

action : correct the appropriate QUEUE command and rerun H_CNC. 


TYPE/ADD | 

cause : the argument, iee., the 2-hexadecimal digit defining 
the address of a "compatible" terminal, specified for 
the ADD parameter of the TERMNL command does not 
correspond with an existing value in the 


configuratione 

action : correct the appropriate TERMNL command and rerun H_ CNC 
uti litye 

TYPE/LINE TYPE 

cause : the "terminal-type" specified for the TYPE parameter 


of the TERMNL command does not correspond to a 
terminal supported by the line procedure. 
action : correct the appropriate TERMNL command and rerun H_CNC. 


TYPE/STYPE 
cause : the "subtype' specified for the STYPE parameter of the 


TERMNL command is not allowed for the "terminal-type" 
specified for the TYPE parameter in the same TERMNL 


command. 
action : correct the appropriate TERMNL command and rerun H_CNG 


Cc-09 


NDL ERROR MESSAGES 


0027 - 0031 


e ERROR CN[0027] SEVERITY@)DUPLICATED STI 


e ERROR CN[0028] 


e ERROR CN[0029] 


e ERROR CN[0030] 


e ERROR CN[0031] 


Syntax : 
cause 


action : 


as denoted 

the same "'Station-index" has been used in more than 1 
STATN command declared for the same line. 

correct the appropriate STATN command and rerun H_CNC 
utility. 


SEVERITY (2)STI NOT SPECIFIED IN POLLING LIST (LINE COMMAND) 


syntax : 
cause 


action : 


as denoted 

the "station-index'" declared in a STATN command has 

not been included in the "polling-list"' of the POLLIST 

parameter in the preceding LINE command. 

- the network control terminai operator can use the 
MTP command to resume polling for the station 

e none 


SEVERITY(3) POLLIST CONTAINS STI OF NOT DECLARED STATIONS 


syntax : 
cause 


action : 


as denoted . 

the "polling-list" of the POLLIST parameter in the 
LINE command has included a "station-index" for which 
no subsequent STATN command has been declared. 

amend the "polling-list" of the appropriate LINE 
command or include the appropriate STATN command to 
follow the LINE command, and rerun H_CNC utility. 


SEVERITY (G)QCPOOL DECLARED BY GENCOM WHILE NO QUEUE USES IT 


syntax : 
cause : 


action : 


as denoted 

a pool of core blocks has been reserved by the QCPOOL 
parameter of the GENCOM command but no subsequent 
QUEUE commands are declared with the QCPOOL option, 
resulting in loss of memory space. 

amend the GENCOM command or QUEUE command(s) and rerun 
H_CNC utility. 


SEVERITY(@)DECLARED SPEED DOES NOT EXIST ON THE UCLA (SRST) 


syntax ;: 
cause : 


action 3: 


as denoted 

the value specified for the SPEED parameter of the 
LINE command defines the line speed for which the DCC 
(data communications controller) is not configured. 
correct the appropriate LINE command and rerun H_CNC 
utility. 


NDL ERROR MESSAGES 
0032 - 0037 


e ERROR CN{0032 SEVERITY (3) QCBLKSZ DECLARED BY GENCOM WHILE NO CORE QUEUE 


e ERROR CN{0033] 


e ERROR CN[0034] 


e ERROR CN([0035] 


e ERROR CN[0036 | 


e ERROR CN[0037] 


DECLARED 


Syntax : as denoted 
cause : e« core block size has been declared in the QCBLKSZ 
parameter of the GENCOM command while no subsequent 
core queues have been specified. 
- the "core queue'' is further defined by, 
- the QCPOOL parameter of the GENCOM command 
- the NUMBLK parameter of the QUEUE command. 
action : amend the GENCOM command or QUEUE command(s) and rerun 
H_CNC utility. 


SEVERITY G) QDBLKSZ DECLARED BY GENCOM WHILE NO DISK QUEUE 
DECLARED 


syntax : as denoted 
cause : e disk queue file block size has been declared in the 
QDBLKSZ parameter of the GENCOM command while no 
subsequent disk queues have been specified. 
- the "disk queue" is further defined by the NUMREC 
parameter of the QUEUE command. 
action : amend the GENCOM command or QUEUE command(s) and rerun 
H_CNC utility. 


SEVERITY (2)NEITHER PROGRAM QUEUE NOR TAP DECLARED 


syntax : no means to log on an application. 
action : none, if the CNC generation is usable 


SEVERITY (3) PROCEDURE NOT SUPPORTED BY URP IMAGE (NROFTCTTOTAL) 


syntax : NROFTCTTOTAL is an SRST entry to the URP. 

cause : the value specified for the TCTNM parameter of the 
LINE command must be greater than the value specified 
for NROFTCTTOTAL 

action : call field engineering service. 


SEVERITY (4)UNABLE TO GET SEMAPHORE 
RC = XXXXXXXX®YYYVYVYVYVY > ZZZZZZ2ZZ 


syntax : the contents of G4 defines the system error. 
cause : system error 
action : call field engineering service. 


SEVERITY (@)UNABLE TO READ LINE TLT 
RC = XXXXXXXX PYYYVYYYY > ZZZZZ22z 


Syntax : the contents of G4 defines the system error. 
cause : system error 
action : call field engineering service. 


NDL ERROR MESSAGES 


0038 - 0044 


e ERROR CN{0038] 


ERROR CN[0039] 


ERROR CN[0040}] 


ERROR CN{0041] 


e ERROR CN 


e ERROR CN[0043] 


SEVERITY (3) OPER TERMINAL DECLARED ON A CLOSED LINE OR STATION 


Syntax : as denoted 

cause : the network control terminal designated OPER in the 
TERMNL command cannot be declared on a LINE or STATION 
for which the CLOSE option has been specified. 

action : amend either LINE or STATN commands and rerun H_CNC. 


SEVERITY (3)AUTO TERMINAL ASSIGNED TO IOF 


syntax : as denoted 

cause : a terminal cannot be declared ASSIGN=IOF as 
well as AUTO because the VCAM subsystems are automati- 
cally scheduled when the terminal becomes ''on-line'. 

action : correct the appropriate TERMNL command and rerun H_CNG. 


SEVERITY (2)MEANINGLESS IN RELEASE 1.D 


Syntax : as denoted 

cause : PTYPE option of LINE command has been retained in 
Release 0400 only for compatibility purposes with 0300. 

action : delete the PTYPE option from the appropriate LINE 
command; the H_CNC run is nevertheless correct. 


SEVERITY (2) REPLACED BY CLOSE IN RELEASE 1.D 


Syntax : as denoted 

cause : INITST parameter has been replaced by CLOSE parameter 
for Release Q400. 

action : correct the appropriate LINE/QUEUE/STATN/TERMNL 
command by either method, 
. replace INITST=INACTIVE by CLOSE 
« suppress INITST =ACTIVE. 
The H_CNC run is nevertheless correct. 


SEVERITY (2)REPORTED TO STEP LEVEL IN RELEASE 1.D 


Syntax : as denoted 
cause : SIMU option must be provided thru the $STEP H_CNC. 
action : amend the #STEP H_CNC in the sequence of JCL statements. 


SEVERITY (3) BUFFER UNIT SIZE INCOMPATIBLE WITH LINE SPEED 


Syntax : as denoted 


' cause : the buffer unit size specified thru BTBFSZ or DABFSZ 


e ERROR CN[0044] 


must be greater than 128 for lines whose speed is great- 
er than 9600 bauds. 

action : correct the relevant parameter in the GENCOM command 
to increase the buffer unit size and rerun H_CNC. 


SEVERITY (2)MIN NUMBER OF BUFFER UNITS FORCED BY GENERATOR 


Syntax : as denoted 

cause : the number of buffer units specified by NBBTBF or 
NBDABF is less than the minimum required by BINS 
according to the number and type of lines. 

action : increase the relevant parameter of the GENCOM command 
and rerun H_CNC; for the current run, H_CNC has forced 
the number of buffer units to the minimum required. 


C-12 


e ERROR Qc(0103] 


e ERROR Qc(0110] 


@ ERROR QC 


e ERROR Qc[0201] 


e ERROR QCc[0302] 


QMAINT ERROR MESSAGES 
0103 - 0302 


SEVERITY (@)ILLEGAL SYNTAX 


syntax : * denotes the element in error 

cause : wrong command name, keyword or argument; violation of 
QMAINT reserved syntax, see Appendix E. 

action : correct the error in the appropriate command and 
rerun H QMAINT utility. 


SEVERITY (4)END OF MESSAGE STRING MISSING 


syntax : as denoted 
cause : after a SEND command, the text of the message must be 
terminated by one of the following methods, 
- the SEND command must contain the ENDMSG option 
- a card delimiter after the last message text card 
specifying //EOM starting at column 1. 
action : e insert the ENDMSG option in the SEND command and 
rerun H QMAINT utility 
« insert the delimiter //EOM at the end of the 
message text and rerun H QMAINT utility. 


SEVERITY (@)MESSAGE SENT TOO LONG 


Syntax : as denoted 

cause : an attempt has been made to send a message text longer 
than the maximum acceptable to MAM, see "Control of 
Message and Queue Overflow'' in Section III. 

action : truncate the message to be sent and rerun H_QMAINT 
utility. 


SEVERITY (4) UNABLE TO ACCESS SYSIN 
RG = XXXXXXXX FYYVYYVYVYY 5 ZZZZZZ2Z 


syntax : the contents of G4 specifies the reason for the abort. 
cause : system error 
action : « check $ASSIGN statement (ASSIGN H_CR) and retry the 
job 
- if error persists, then call the field engineering 
service. 


SEVERITY (2)INVALID NAME LENGTH : name 


syntax : '"name'' specifies the external-queue-name used in the 


QMAINT command concerned. 
cause : ''name'' must obey the following rules, 
« limited to up to 4 alphanumeric characters 
» specified previously in a corresponding QUEUE 
command, see Section V. 
action : correct the queve name in the appropriate QMAINT 
command and rerun H QMAINT utility. 


QMAINT ERROR MESSAGES 


0304 - 0409 


e ERROR Qc[0304] 


e ERROR Qc[0307] 


e ERROR Qc[0308| 


e ERROR Qc[0405] 


e ERROR QC[0409] 


SEVERITY (@) DUPLICATE KEYWORD 


Syntax : as denoted 

cause : a keyword has occurred more than once in a command. 

action : correct the appropriate command and rerun H_QMAINT 
utility. 


SEVERITY (2) QUEUE UNKNOWN : name 


syntax : 'name!'' specifies the external-queue-name used in the 
QMAINT command concerned. 

cause : 'name' is not defined for a queue in the network 
declared. 

action : check ''name'' against the list of all external-queue- 
names defined for the network. 
correct the "name! in the appropriate QMAINT command 
and rerun H_QMAINT utility. 


SEVERITY (2) QUEUE NOT AVAILABLE : name 


syntax : '"name'' specifies the external-queue-name used in the 
QMAINT command concerned. 

cause : "name'' identifies a queue currently allocated to an- 
other application program, iee., if a program queue, 
or to a terminal still logged on, ieee, if a terminal 
queue. 

action : wait until the queue identified becomes available and 
then rerun H_QMAINT utility. 


SEVERITY (4)FAILED TO CREATE SEGMENT : segment-name 
RG = XXXXXXXX FYYYVYYVYYY» ZZZZZZ2ZZ 


syntax : '"'segment-name" specifies the internal name of a work 
segment that H_QMAINT was unable to create. 
the contents of G4 specifies the reason for the abort. 

cause : system error 

action : retry : if the same condition persists, then call the 
field engineering service. 


SEVERITY (3) ABNORMAL RECEIVE FROM QUEUE : name 
RG = XXXXXXXX PYVYYVYVYVY» ZZZZZZ22Z 


Syntax : 'name'' specifies the external-queue-name to which a 
RECEIVE was issued. 
the contents of G4 specifies the reason for the abort. 

cause : system error (MAM) 

action : retry : if the same condition persists, then call the 
field engineering service. 


QMAINT ERROR MESSAGES 
0412 


e ERROR QC{0412] SEVERITY (@)ABNORMAL SEND TO QUEUE : name 
RG = XXXXXXXX FYYYVVYVVYY» ZZZZZZ2Z 


Syntax : "name'' specifies the external-queue-name to which a 
SEND was issued. 
the contents of G4 specifies the reason for the abort. 

cause : system error (MAM) 

action : retry : if the same condition persists, then call the 
field engineering service. 


JOR ERROR MESSAGES 


CC16 BINS ERROR RC= XXXXXXXXPYYVYVYVVVYY 5 ZZZZZ2Z2Z 


Syntax : the contents of RC specifies the system error. 

cause : abnormal termination of BINS due to system error. 

action 1 :if zzzzzzzz=CONFLICT, BINS has been started for a network with- 
out LINE definition; correct NDL description, rerun H_CNCG. 


action 2 :for any other value of zzzzzzzz, call field engineering service. 


CC17 SITE CONTROLLER FLAW : LINK SEM. POOL OVERLOADED 


syntax : as denoted 

cause : BTNS site controller has aborted due to an overflow on the 
telecommunications semaphore segment, ieee, no more free links 
are available. 

action : notify field engineering service. 


CC23 UNABLE TO ACCESS NETWORK FILE RC = xxxxxxxx-yyyyyyyy ZZZ22Z22 


Syntax : the contents of RC specifies the error and the system primitive. 
cause : BTNS has been unable to access the network file created by H_CNC 
utility during the start-up phase. 
action : retry : if repeatedly unsuccessful, 
- perform ISL with "restart clean" option 
» generate the network. 


CC24 pINs ALREADY ACTIVE 


syntax : as denoted 

cause : only 1 BINS step may be active at any one time. 

action : terminate the current version by the TT [stRoNG] network control 
command and then restart a new version by the ST network control 
command. 


CC29 TRANSMISSION CONTROL BUFFER OVERLOAD : ssssssss 


Syntax : ssssssss is the hexadecimal segment address of the buffer in 
question. 

cause : transmission by BTNS has failed due to lack of buffer units, 
e either in the BTNS buffer pool, ieee, segment D.44 
» or in the VCAM buffer pool, ieee, segment D,. 43. 

action : increase the number of buffer units of the segment in question 
using either NBBTBF or NBDABF parameters of the GENCOM command. 
correct the GENCOM command and rerun H_CNC utility. 


CC34 BINS IRRECOVERABLE ERROR, REASON : xxxxxxxx 


Syntax : XXxxxxxx gives the reason for failure 
cause ; error in BINS 
action : call field engineering service. 


JOR ERROR MESSAGES 


CNO1 UNABLE TO FORMAT QUEUE FILE RC = xxxxxxxx*yyyyYyVy > 22222222 


syntax : 
cause 


action : 


the contents of RC specifies the error and system primitive. 

the attempted CNC generation has been aborted due toa disk error 
while formatting the disk queue file. 

retry : if the failure recurs, reallocate the file in a different 
area of the same disk or to another disk. 


CNO2 ERROR DURING {CLOSE JOPEN|PUT} SYSOUT RC = xxxxxxxxyyyYYYYY 5 ZZZZZ22Z 


syntax : 
cause : 


action ; 


the contents of RC specifies the system error. 

the attempted CNC generation has been aborted due to the error 
appropriately indicated during a SYSOUT file access. 

retry 


CNO3 UNABLE TO CREATE NETWORK FILE RC = xxxxxxxx®yyyyyyyy , ZZZZZZ2z 


syntax : 
cause 


action : 


as denoted 

the attempted CNC generation has been aborted due to an abnormal 
condition while copying the telecommunications system tables into 
backing store. 

retry : if repeatedly unsuccessful, 

« perform ISL with "restart clean" option 

» generate the network 


CNO4 TELECOMMUNICATIONS SESSION IN PROGRESS 


syntax : 
cause ; 


action : 


as denoted 

the attempt to execute the H_CNC utility has been aborted while 
BINS, TDS, an MCS COBOL step or another CNC session is running. 
try later. 


CNO5 INVALID OPTIONS STRING 


syntax : 
cause : 


action 3: 


DAOO vcaM NOT 


syntax : 
cause : 


action ; 


as denoted 

the option specified in the CNC $STEP statement is other than 
OPTIONS = 'SIMU'. 

check the CNC $STEP statement and retry. 


AVATLABLE 


as denoted 

the attempt to start BTNS, IOF, ROF or TDS, or batch entry has 
been aborted because no network has been createds 

run H_CNC utility. 


JOR ERROR MESSAGES 


QCOO MAM NOT AVAILABLE 


syntax 
cause 


action 


as denoted 

the attempted MCS COBOL step has been aborted because, 

» the H_CNC utility has not been run to create the network 

- a CNC session is running 

- the step is multiprocess and was not linked with the Linker 
command LINKTYPE = BMAM. 

perform aS appropriate, 

e run H_CNC utility to create the network 

« try later 

- link the step. 


QCO1 MAXIMUM NUMBER OF QASSIGN STATEMENTS IS EXCEEDED 


syntax 
cause 


action 


as denoted 

the attempted MCS COBOL step has been aborted due to more than 
24 $QASSIGN statements in the step enclosure. 

respecify JCL and retry. 


QCO2 external-queue-name UNKNOWN EXTERNAL QUEUE NAME 


syntax : 


cause 


as denoted 

the attempted MCS COBOL step has been aborted because a §$QASSIGN 
Statement specifies an "external-queue-name' that is not defined 
in the network descriptiom 


action : « respecify NDL and rerun H_CNC utility. 


e retry the MCS COBOL step. 


QCO3 external-queue-name QUEUE NOT AVAILABLE 


Syntax : 


cause 


e 
e 


action : 


as denoted 

the attempted MCS COBOL step has been aborted because a $QASSIGN 
Statement specifies an "external-queue-name" currently allocated 
to another MCS COBOL step. 

retry later. 


QC04 symbolic-queue-name DUPLICATE SYMBOLIC QUEUE NAME 


Syntax 
cause 


action : 


as denoted 

the attempted MCS COBOL step has been aborted because a $QASSIGN 
statement specifies a "symbolic-queue-name'' that has already 
been assigned in another $QASSIGN statement of the same step. 
respecify JCL and retry. . 


QC05 external-queue-name DUPLICATE QUEUE NAME 


syntax 
cause 


action : 


as denoted 

the attempted MCS COBOL step has been aborted because a $QASSIGN 
Statement specifies an "'external-queue-name"' that has already 
been assigned in another $QASSIGN statement of the same step. 
respecify JCL and retry. 


JOR ERROR MESSAGES 


QCO7 MAM : ABORT USER RC=xxxxxxxx-¥yyyYYYYy  2Z22222z 


syntax : the contents of RC specifies the system error. 

cause : the MCS COBOL step has been aborted due to an error condition at 
run-time. | 

action : see "List of Return Codes" 


QCO8 process-name : UNABLE TO START USER PROCESS 


Syntax : applicable only to a multiprocess step 

cause : the MCS COBOL step has been aborted because a uSer process 
appropriately identified cannot be started, 

action : check the report of the linking process for the load module. 


Qcos UNABLE TO OPEN CTIVF FILE RO= xxxxxxxxyyyyyyVYV » 22222222 


syntax : the contents of RC specifies the error and system primitive. 
cause : the system file containing the network description is unable to 
be opened due to a system error. 
action : proceed as follows, 
« perform ISL with "restart clean" option 
* generate the network 


QC10 UNABLE TO ACCESS CIVF FILE RC= xxxxxxxxyyyyyyyy 5 22222222 


syntax : the contents of RC specifies the error and system primitive. 
cause : the system file containing the network description cannot be 
accessed due to a system error. 
action : proceed as follows, 
- perform ISL with "restart clean" option 
» generate the network. 


QC11 QUEUES FILE MEDIA BUSY/NOT AVAILABLE 


Syntax : as denoted 

cause : the disk queues file is not available for MCS processing or has 
not been mounted. 

action : perform as appropriate, 
« retry later 
» mount the disk medium as specified. 


QC12 MAXIMUM NUMBER OF MAM PROCESS GROUPS EXCEEDED 


syntax : as denoted 

cause : the number of MCS COBOL process groups has exceeded the number 
specified for the MAMNB parameter of the GENCOM command. 

action : correct the GENCOM (NDL) command and rerun H_CNC utility. 


JOR ERROR MESSAGES 


QC14 INVALID KEYWORD REPLY IN QASSIGN 


syntax ; 
cause 


action ;: 


as denoted 

a $QASSIGN statement includes a "reply"! keyword which does not 
specify a program queue. 

respecify JCL and retry. 


QC15 UNABLE TO ACCESS SYSOUT RC = xxxxxxxx SYYYYYYYY » ZZ2Z2Z222 


Syntax : 
cause 


action : 


the contents of RC specifies the reason for the abort and the 
system primitive. 

QMAINT processing was aborted due to an error in accessing the 
SYSOUT file. 

retry : if the same condition persists, then call the field 
engineering Service. 
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Code Definition 


Operator Action 


CONFLICT 


Code Definition ; 


Action ; Operator 
‘Programmer - correct NDL pack and rerun H_CNC utility 


COUNTOV 


LIST OF RETURN CODES 


an invalid internal condition, ege, invalid data or data 
out-of-range, was detected during processing a disk 1/0 
request with a result that file processing is now 
discontinued. 

take a dump and notify field engineering service. 


BINS has been started for a network generated without LINE 
definition 
- none 


Code Definition : the threshold of I/O errors defined at initialization has 


Operator Action 


Code Definition 


Operator Action 


Code Definition 


Operator Action 


Code Definition 


Operator Action 


e 
e 


been exceeded with a result that the pending I/O operation 

is not executed and a shutdown has occurred. 

proceed as follows, 

« try to copy the file affected 

» if the file fails to be copied, then a new file must be 
preallocated, the system reinitialized and the network 
regenerated. 


a channel program error or hardware malfunction has 
occurred. 

proceed as follows, 

« retry the step 

- if unsuccessful, notify field engineering service. 


an internal error while trying to start multiple channel 
programs simultaneously has occurred. 
notify field engineering service. 


a request has been made to read or write a record outside 
the limits of the allocated file 

proceed as follows, 

« retry the step 

- if unsuccessful, notify field engineering services 
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LIST OF RETURN CODES 


continued 


Code Definition : the file was not in the "'ready'' state when accessed by an 


Operator Action : 


Code Definition : 


Operator Action : 


NEXPDERR 


Code Definition : 


Operator Action : 


Code Definition 


I/O operation. 

proceed as follows, 

e set the drive to the "ready' state or mount the disk on 
another drive and set it to "ready" 

. retry the step with MAM=YES. 


a disk I/O request specifying an invalid number of records, 
eege, less than O or greater than 5, has been attempted. 
take a dump and notify field engineering service. 


either VCAM or MAM has been pre-loaded and "locked" in me- 
mory thereby preventing the execution of the H_CNC utility. 
use the CMM command to cancel the appropriate "locked" seg- 
ment and rerun H_CNC utility. 


: an internal system error has occurred. 


Operator Action : notify field engineering service. 
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APPENDIX D 


The program is an example of validating data exchanges with 


. VIP?7700 : printer and cassettes (1 or 2). 
The program exchanges data with one terminal at a time as follows: 


sends a file of identical data blocks to a selected cassette 
through the CAS symbolic queue 

sends a file to the printer through the PRT symbolic queue 
receives the file previously transmitted from a cassette 
through the QAB symbolic queue 


For each possible mode of operation, the program displays the option 
with the applicable answers for the console operator to select. A 
detailed description for operating the program appears as comments 


in the listing following. 


FORMAT OF BLOCKS 


The 3 types of block format used are for 
+ sending data to a cassette 
e Yreceiving data from a cassette 
» sending data to the printer for hard copy 


Block Format for Transmission to Cassette 
. 
><zSC\, *><ESCS >< FFynnnn «data» 


ta See 
: ; 
q / 


<2 ot | = << — plock-number, starting at. cool 


| | form feed control character 
| write command 

— cassette selection, B = cassette handler 1 
F = cassette handler 2 
_ 


> < ESC: >> <ESCS >SFFVEOF format of "“end-of-file* block 


Ko 


format 
? of 
oss block 


Block Format for Transmission from Cassette 


‘ 


ne os Cease > format of data block 
ltplock-number, consecutively numbered J 


EOF format of "“end-of-file" block 
Block Format for Transmission to Printer 


nnonn <« data» 
— Ser 
| 


—block=number, starting from 0001 


HANDLING OF DATA 


Each data block is transmitted as a separate message. After each 
operation, the STATUS KEY and the ERROR KEY are checked for abnormal 
conditions. The program displays any abnormal condition and terminates, 


Data sent from or received into the working area is recorded on the 
SYSOUT file. 


Before data is sent to or received from the cassette handler, the 
program issues a rewind command of the format: 


f 


> <esct 5 > > <ESCP 
a 


ey “oe rewind command 
ee ened 


‘-cassette selection, E = cassette handler i 
F = cassette handler 2 
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NETWORK GENERATION 


Terminals 

declared Physical Symbolic: 

by CNC queues queues 

declared declared 
screen by by 

or CNC pQASSIGN 
key board/ a, geEacu Sy) bee ve 
sis  STAL | | PQCT | QAB 
| cassette | v77i.| Istation \ | BINS, VE7K CAS | 
| @ | | Se 
ae | _ |G aa ere 
, , a : eee (V27P | PRI | 


_ pFinter | 


The transmission mode of the terminals is 
default options, IM=NL and OM=NL, because 
needed on input dut must be translated on 
forms (e.g., , >< ESC). 


The screen or keyboard/screen is not addressed by the program 
it is declared the master terminal. 


In the NDL statements that follow, the points to be noted are, 


TQCI, 
parameters, 


test 


program: 


! 
‘ 
swsianin onal 


declared with the following 
control characters are not 
output as standard mark 


Since 


VIP7700 is automatically logged on to the program queue 
Since it has been declared with the ASSIGN and AUTO 


Terminal queues are defined on disk because V77K and V77P 


must be able to contain a series of messages the number and 
size of which are specified by the L64 console operator in 


response to a program request, 


The program queve TQCI is declared in memory and is defined 


to contain 1 message at a time; each time a message is queuei, 
the program receives it and then requests the next message to 


be read. 
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NDL STATEMENTS FOR VIP7700 CWITH CASSETTES AND PRINTER) 


STATN STA1,1; 

TERMNL V77S,TYPE=VIP7700,STYPE=KCT; 
TERMNL V77K, TYPE=SLAVE, STYPE=CAS; 
TERMNL V77P, TYPE=SLAVE, STYPE=PRT; 


NDL STATEMENTS FOR QUEUES 


QUEUE V77S; 
QUEUE V77K; 
QUEUE V77P; 


QUEVE TQCI,NUMBLK=30; MEMORY QUEUE 
JCL STATEMENTS FOR COMPILING, LINKING AND EXECUTING THE PROGRAM 


$JOB VIP,USER=JL, PROJECT=SUP4, BILLING=BILL4, CLASS=H; 
SCOBOL SOURCE=*TSTROVIP, 

, OBULIST, XREF,LEVEL=L64, 
CULIB=C(CCTL-40. TCULIB, DEVCLASS=MS/M400,MEDIA=C122); 
SINPUT TSTROVIP, TYPE=COBOL; 

SENDINPUT; 

LIB CU 

, INLIB1=CCCTL_40. TCULIB, DEVCLASS=MS/M400,MEDIA= C122) 
, INLIB2=CSYS.HCULIB); 

LINKER VIPTEST,ENTRY=VIPTEST 
,OUTLIB=(MCS.LMLIB,DEVCLASS=MS/M400,MEDIA=C122) 

, COMFAC; ; 

STEP VIPTEST , FILE=(MCS.LMLIB , DEVCLASS=MS /M400 ,MEDIA=C122) ,DUMP=DATA; 
QASSIGN QAB,TQCI, IN; 

QASSIGN CAS,V77K, OUT; 

QASSIGN PRT,V77P,0UT; 

ENDSTEP; 

SENDJOB; 


6/79 
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MCS COBOL PROGRAM EXAMPLE 


IDENTIFICATION DIVISION. 
PROGRAM-ID. VIPTEST. 
AUTHOR. JL. 
DATE-WRITTEN. FEB 10 78. 
KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KK KKK KK KK KKK KKK KKK KKK KKK Kk 
* PROGRAM IS A SIMPLE TEST PROGRAM FOR: 
* VIP7700 WITH CASSETTE AND ROP 
*IT ALLOWS ON BEHALF OF THE GCOS64 SYSTEM OPERATOR 
* TO PERFORM THE FOLLOWING FUNCTIONS: 
- READ ANY FILE FROM A DATA CASSETTE PREMOUNTED 
ON THE VIP CASSETTE DRIVE #1 OR #2 
- DATA BLOCKS MAY BE OF ANY SIZE UP TO 
192C BYTES 
- THE LAST BLOCK OF THE FILE MUST BE EOF 
(END OF FILE) 
- WRITE A FILE ONTOS” OUT OT 
-A DATA CASSETTE PREMOUNTED ON THE CASSETTE 
DRIVE #1 OR #2 
- THE HARD-COPY 
-~ DATA SLOCK GENERATED 3Y THE PROGRAM 
MAY BE OF ANY LENGTH UP TO 1916 BYEST 
- END OF FILE BLOCK (EOF) TS GENERATED 
AUTOMATICALLY 8Y THE PROGRAM AT THE 
(NO FOF GENERATED FOR HARD=COYPY FILES) 
END OF WRITE SEQUENCE 
- THE TYPE OF TERMINAL IS CONFIRMED THRU THE 
SYSTEM CONSOLE QUESTION: 
‘CONFIRM TERMINAL TYPE “CVIP)Y — 
ANSWER =: VIP FOR viIP7709 
THE TYPE OF OPERATION IS SELECTED BY THE 
SYSTEM CONSOLE QUESTION: 
TYPE OF OPERATION ? 
ANSWER 3: 


“TO READ A FILE FROM CASSETTE  —— 
TO WRITE A FILE ONTO CASSETTE 
TO WRITE A FILE ONTO HARD-COPY 
FE TO END THE PROGRAM 
- THE CASSETTE DRIVE IS SELECTED THRU THE 
SYSTEM CONSOLE QUESTION : 
CASSETTE DRIVE #4 2? ~ 0707 
ANSWER : 

1 FOR DEVICE ADDRESSED THRU “ESCE™ 

2 FOR DEVICE ADDRESSED THRU "ESCF" 
SQASSIGN JCL RUN-TIME COMMANDS MUST DECLARE 
THE FOLLOWING SYMBOLIC QUEUES : 

- Q@AB FOR THE PROGRAM QUEUE = 

- CAS FOR THE CASSETTE QUEUE 

“= PRT FOR THE HARD-COPY QUEUE 
- AT CNC GENERATIGN TIME THE CASSETTE AND HARD- 
COPY MUST BE DECLARED AS WORKING IN: ; 

- INPUT NORMAL MODE 

* - OUTPUT NORMAL MODE 


kkk kk KR KK KR kk kk kk ko kk kk a IK ek 


veiw 


+e ee FOF OF OF OF OF OF OO OOO OOOH 
I 


k 
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ENVIRONMENT DIVISION 


* 


Rk KK RR KKK KK KK RK KK KK KKK KEK KE KKK ER KRKE RE KK KR TOT 


* 
k 


ENVIRONMENT DIVISION 


FTO IO I III kk kok kk ek 
ENVIRONMENT DIVISION. © . Se 
CONFIGURATION SECTION. 

SOURCE=COMPUTER. LEVEL -64. °° 

OBJECT-~COMPUTER. LEVEL-64, 


DATA DIVISION 


k 


“2 
* 


KAEKKEKK KK KEKE KKK KKK KKK KK KEKKKEK KKK KE KKK KKK KEK KEKK KK KKK KKK 


DATA DIVISION 


KKK KEK KKK KR KKKEKKKKEKKK AK KE KKK KEKKEK KKK EK KK KK KKK 


DATA DIVISION. 


DECLARE WORK VARIARLES 


WORKING-STORAGE SECTION. 

TRTYP PIC XXX. 

DRIV PIC X. 

COMMAND TO REWIND CASSETTE 41 

RWND PIC X(12) VALUE "><ESCE><ESCP", 
INIT1 PIC 9999 VALUE 1. 

1DX1 COMP-1. 

1DX2- COMP=1. 


77 


77 
* 
77 
77 
77 


77 


* 


77 
07 


* 


01 


* 
01 


COMMAND TO READ CASSETTE 41 


SROC1 PIC x(€12) VALUE “><ESCE><ESCR". 
CONS-MED. 


02 


Oe 


COMMAND TO WRITE CASSETTE #41 
CMND PIC xX(€12) VALUE “"><ESCE><ESCS". 
FORM FEED CHARACTER eee 
FORME PIC x(5) VALUE "D><FF ", 


DUM. 


ie RDY PAD Kin 
SIZE AND NUMBER OF BLOCKS TS RE WRITTEN 


CARI. 


ie 
e 


CHAR 1 Po RB) 

CHAR2 REDEFINES CHARI. 

OS" BLKSZ PIC 9999% ie erga a 

03 BLKSEP PLC Xe 

03 ‘BLKNS “PIC 999, 
INPUT WORK AREA TO CONTAIN BLOCKS RECEIVED FROM 
CASSETTE 


INSUF, 


N2 
ie 


IN31 PIC Xt 200035 

INB3 REDEFINES INB1, 

03 INS331 PIC XXX, 

03 INB32 PIO ROT99 7%) 4 
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OUTPUT WORK AREA TO CONTAIN: — J 
- READ COMMANDS SENT TO CASSETTE #1 
- DATA SLOCKS SENT TO CASSETTE #2 © 
01 OUTBUF. 
2 OuT1 PIC x(17). 
02 OUT2 PIC 9999, 
02. OuT21 REDEFINES OuT2. 
03 OUT 22 PIC XXXX, 
02 ouUT3 occurs 2000. 
03 OUTS PIC X, 
01 OUTI1. 
02 OUT12 PIC 9999, 
02 OUT13 OCCURS 2017. 
03 0UT131 PIC X. 


* DECLARE COMMUNICATIONS STRUCTURES 


COMMUNICATION SECTION. 
* DECLARE CD FOR INPUT 


CD CDIN FOR INPUT 
SYMBOLIC QUEUE IS SYMBOQN 
MESSAGE DATE IS DATI 
“MESSAGE TIME 1S. TIMI 
SYMBOLIC SOURCE IS SYMBSOR 
TEXT LENGTH TS. FXPLGTH 
END KEY IS ENDKEY 
STATUS KEY IS STATKEY 
MESSAGE COUNT IS MESCNT. 


* DECLARE CD FOR OUTPUT 


CD CDOUT FOR OUTPUT 
DESTINATION COUNT IS DESTECNT ~ 
TEXT LENGTH IS TXTLH 
STATUS KEY IS STATOK 
ERROR KEY IS ERRKEY 
SYMBOLIC DESTINATION IS SYMBDES, 


PROCEDURE DIVISION 
/ 


Oko kk OK kK kk Oe OK Kk kk kk kk kk 
* 
* 7 PROCEDURE DIVISION - 
Kk kk KKK KK KKK KKK KKK KKK Kak kha hha kkk kkk kkk kk kkk 
PROCEDURE DIVISION. 
STARTX. 
DISPLAY "xxx STARTING TEST ***"™ UPON CONSOLE. 
* INET TALLIES 
“MOWE T° TO “DESTCNT. 
INITIALIZE: 
- SYMBOLIC QUEUE FIELD OF CD FOR INPUT 
WITH SYMS30LIC NAME DEFINED RY RUN-TIME JCL 
(ILE. SQASSIGN CARD) 
MOVE "QAR" TO SYMBQN, 


* * & 
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Kak kkk kk KKK KEKK KKK KKK KR KKK KKK KKK KK KK KKK KK KK 


7 “TERMINAL CONFIRMATION 


kKikkhkkk kok kkk k tk tk kkk kkk k tk kk kk kok 
TRMTYP, 


DISPLAY "CONFIRM TERMINAL TYPE (VIP)" UPON 
“ACCEPT TRIYP FROM CONSOLE. 

bE TREYP = VIP’ GO TO. DISRDY. 

PERFORM ERROPT. 

GO TO TRMTYP, 


kkkkkeke keke kkk keke kkk Ke KK KKK KKK KK KKK KKK KKK KKK 


* ~~ OPERATION TYPE SELECTION 


Ka KK KKK KKK KKK KK KKK KK KKK KKK KKK Kaka KK hha Kh Kh Kk Kak 


* ASK FROM THE SYSTEM CONSOLE WHICH TYPE OF OPE 
* TO PERFROM: 

- READ A FILE FROM CASSETTE 

x "o> S WRITE A FILE ONTO CASSETTE 

‘ - WRITE A FILE ONTO HARD-COPY 

“ “= TERMINATE THE SESSION 

DISRDY. 


DISPLAY "TYPE OF OPERATION ? (Rete Ps OR FE)" 
ACCEPT RDY FROM CONSOLE. 
IF RDY = "R" GO TO DRIVE. 


IF RDY = “W" GO TO DRIVE. 
TF ARDY = "PR" GO TO VPRIF ICs 
DP RDY = "E™ G0) TOF UNG 


PERFORM ERROPT. 
GO TO DISRDY. 
FO OO IO I kk kk bok 


* CASSETTE DRIVE SELECTION 


akk keke aK KKK KKK KK KEK KKK KEK KKK KEK KKK KE KKK KKK KK 


CONSOLE 


RATION 


UPON CONSOLE 


DRIVE. 

a ENITIALIZE:?: 

* - SYMBOLIC DESTINATION FIELD OF CD FOR OUTPUT 
* WITH SYMBOLIC NAME DEFINED BY RUN-TIME JCL 
* CILE.SQASSIGN CARD) 


MOVE "CAS" TO SYM8DES. 
DISPLAY “CASSETTE DRIVE 4 2? €1 OR 2)" UPON 
ACCEPT DRIV FROM CONSOLE. 
IF DPRIV = “1 GO TO ODORIVI.L 
‘TF pRIv- = “o" GO TO BRIV2. 
PERFORM ERROPT. 
GO TO DRIVE. © 

* DRIVE H2 SELECTED 

DRIV2. 
MOVE “D><ESCFO<ESCP™ TO 2aNd. 
MOVE “"><ESCF><ESCR" TO SRICI. 
MOVE "><ESCFO<ESCS™ TO CNA, 
GO TO ORIVS. 

* DRIVE #41 SELECTED 
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CONSOLE. 


DRIV1. 
MOVE "><ESCE><ESCP” TO RWND. 
MOVE "ESCE><ESCR™ TO SRDC1. 
MOVE "D><ESCE><ESCS™ TO CMND. 
DRIV3. 
IF RDY = "Ww" GO TO WRITE-CAS, 
IF RDY = "R™ GO TO READ=-CAS. 
Rew eK KK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK K 
x READ A FILE FROM CASSETTE 
RAK KKK KK KKK KKK KKK K KKK KKKEKKK KKK KK KK KKK KK 
READ-CAS. 
k REWIND CASSETTE 
PERFORM REWIND1. 
* LOOP READING THE CASSETTE UNTIL THE END OF FILE 
* “BLOCK CEOF) IS FOUND THEN RETURN TO THE OPERATION ~~ 
* TYPE SELECTION 
LOOP-READ. 
* INITIALIZE THE OUTPUT WORK AREA WITH TEXT OF 
* CASSETTE READ COMMAND CESCE ESCR) | 
MOVE SPACES TO OUTBUF. 
MOVE SRDC1 TO OUTBUFL 
* INITIALIZE. TEXT LENGTH FIELD OF OUTPUT CD_ 
MOVE 12 TO TXTLH. . 
SEND THE READ COMMAND TO THE CASSETTE THEN CHECK THAT. 
THE SEND HAS BEEN SUCCESSFULL 
PERFORM SENDING-MEDIUM, 
DE RRORM RETURN SENDING (0 Se ee SS Sei 
* RECEIVE THE READ BLOCK FROM THE PROGRAM QUEUE 
* (QA8) THEN CHECK THAT RECEIVE HAS BEEN. SUCCESSFULL 
MOVE SPACES TO INBUF. 
PERFORM RECV. 
PERFORM RETURN-RECV. 


—* CHECK IF CAST BLOCK OF THE FILE CEQFY 00s 


*  — WRITE A FILE ONTO CASSETTE 


*: 


IF INB31 = “EOF™ GO TO DISRDY. 
GO TO LOOP-READ, eee ta ee 
clalialielehalialeMalaleleialeliaielioieleliclabeielehelehohshelichelicloieleleloletelehoialeleiots 


KKK KKK KEKKKAKKKK KKK KR KKK KKK KK KK KKK KKK KKK KK KK KKK 


WRITE-CAS. 

* REWIND CASSETTE ~~ 
PERFORM REWIND1. 

“WRITE THE DATA FILE 
PERFORM WRITFIL THRU END-WRITFIL. 


—* “WRITE END OF FILE BLOCK, CHECK THAT SEND OPERATION ~~ 


* HAS BEEN SUCCESSFUL THEN RETURN TO OPERATION TYPE 
SELECTION = | = — 
WR-EOF. 
— MOVE CONS-MED TO” oursury 
MOVE "EOF " TO OUT22. 
~ MOVE 27° TO TXTUHS 
PERFORM SENDING-MEDIUM, 
PERFORM RETURN=SENDING. 
GO TO DISRDY. 


Ee EN ee een ee ee LR eee 


D-09 


x WRITE A FILE ONTO HARD-COPY 


KAR KKK KK AK KK KKK KKK Kh KKK KKK KKK KKK KKK KR KKK KEK 


PRTFIL. 
CHECK OPERATION ALLOWED 
INITIALIZE? 
- SYMBOLIC DESTINATION FIELD OF CD FOR OUTPUT 
WITH SYMBOLIC NAME DEFINED BY RUN-TIME JCL 
(I.E. SQASSIGN CARD) 
MOVE "PRT" TO SYMBDES, 
WRITE THE DATA FILE 
PERFORM WRITFIL THRU END-WRITFIL. 
GO TO DISRDY. 


+ + F&F + 


+ 


kaa KKK KK RK KK KKK KKK KKK kK KK KKK KKK KKK KKK Kha KK KKK 


* SUBROUTINES 


kkk kkk kk kkk kh keke Kaa KKK aKa KK Kh Kha hhh hk kK ahh kkk 


Rok Ok I OO ok kok 
a “ WRITE A DATA FILE TO CASSETTE 7 
* OR HARD-COPY 


kak KKKe KR KK KKK KKK KKK AK KK KKK KK KKK KAR KKK KKK KK KKK KK 


WRITFIL. 
MOVE SPACES TO OUTSBUF. 
MOVE SPACES TO OUT11. 
* ASK NUMBER AND SIZE OF BLOCKS TO BE WRITTEN 
SIZN8. 
DISPLAY "SIZE/NUMBER ? (XXXX/XXX)"™ UPON CONSOLE. 
ACCEPT CAR1 FROM CONSOLE. 
IF BLKSEP NOT = "/" 
PERFORM ERROPT 
GO TO SIZNB. 


* CHECK TYPED BLOCK SIZE COMPATABLE WITH TERMINAL TYPE 


IF BLKSZ > 1916 
PERFORM ERROPT 
GO TO SIZNB. 
en ee BAS Bee, 4S UEA Ae Fuses es Beet teens 
MOVE 1 TO IDX1. 
* FILL OUTPUT BUFFER WITH "A™ CHARACTERS 
LOOP1. 
IF RDY = "pt 
MOVE "A™ TO ouT13 C1DK1) 
“GO TO LOOPITs ~~ bp Ee ree ening Mere aia 
MOVE nae TO ours CTOx1). 
te Ui OOP + 1< eee, a ‘ List attendee ts he ta pO ke en 
ADD 1 TO IDX1. 
IF IDX1 NOT > BLKS2° GO TO LOOP1. 
* INITIALIZE BLOCK COUNTER 
ween ie etiiy M 6) YE-- 1 oom TO— IT) Xx? Gay eee Patacsa pesca pucitbert ation anes "Getta =" ead satan Se SS gas sn ie “passa Spat aia FL a Narita atseantas Mok 
IF RDY = "P"™ GO TO PRT1. 
ADD 17 TO BLKSZ. 
* MOVE WRITE COMMAND TO OUTPUT BUFFER 
bee MOVE CONS=MED TO OUT1T. Pen Beg pi rree i reas 
* MOVE BLOCK NUMBER TO OUTPUT BUFFER 


MOVE INIT1 TO OUT2. 
GO TO PRT2. | — 
* MOVE BLOCK NUMBER TO OUTPUT BUFFER (FOR HARD=-COPY) 


PET hs 

MOVE INIT1 TO OUT12. 
PRIds 

ADD 4 TOS BLKSZ. 
LOCP2. 


IF ROY = "P™ MOVE OUT11 TO OUTS3UF. 

MOVE BLKSZ TO TXTLH. 
x SEND THE DATA BLOCK TO THE TERMINAL QUEUE THEN CHECK 
* THAT THE SEND OPERATION HAS BEEN SUCCESSFULL 

PERFORM SENDING-MEDIUM, 

PERFORM RETURN-SENDING. 

DISPLAY "OUTPUT= " OUTBUF. 
* INCREMENT BLOCK COUNTERS 

IF RDY = “p" 

ADD 1 TO OUT12 

GO TO INCR1. 

AOD A> Teor ODT2< 
Incetoc ccm 

ADD 1 TO IDX2. 

IF IDX2 NOT > BLKNS GO TO LOOP2, 
END<-WRITFIL. 
KKKKKKKAKKR KKK KKK KKK KKK KEK KKK KKK KEK KKK KKK KR KKK KKK K 
x SEND A READ COMMAND OR A DATA BLOCK 
ck TO CASSETTE QUEJE ss 
KKK KKK KEK KKK KEK KKK KKK KKK KKK KK KKK KK KK KKK KKK KEK SK 
SENDING-MEDIUM. 

SEND CDOUT FROM OUTBUF WITH EMI, 
END-SENDING-MEDIUM, 
KEK KKK KK KKK KKK KK KKK KKK KKK KKK EK KE KEKEKKKKE KK KK KKK KK 


~* CHECK SEND SUCCESSFUL 


RETURN-SENDING. 
IF STATOK NOT = "OO" DISPLAY “OUTPUT STATUS IS " STATOK 
UPON CONSOLE GO TO FIN. | | 
IF ERRKEY NOT = "O" DISPLAY “OUTPUT ERROR KEY IS " 
~ERRKEY UPON CONSOLE GO TO FIN, | 
END-RETURN-SENDING. 


kkk kkk kkk eR aK KKK KKK KEKE KEK KKKEKEKKKKKKKKKEKKKEK KK KEK 


* RECEIVE A BLOCK FROM Q@ASB QUEUE 


RECV. 
RECEIVE CDIN MESSAGE INTO INBUF. 
DISPLAY “INPUT = " INBUF,. 
END-RECV. . 


wa KKK KKK KKK KK KKK KKK KKK K KKK KEK KK KK KKK KEK 


* CHECK RECEIVE SUCCESSFUL. 


RETURN-RECVE Sy yee Sees Sea Nees Seo ahd a! Se as 
IF STATKEY NOT = "OO" DISPLAY “INPUT STATUS IS " 
STATKEY UPON CONSOLE GO TO FIN. | 

IF ENDKEY NOT = "3" DISPLAY “ENDKEY IS " ENDKEY 
UPON CONSOLE _ ~~ 
GO-TO. FIN. 


END-RETURN-RECV. 


kkk kkk ke Kha KKK KKK KKK KKK KKK KKK KKK KAM KKKE KKK KKK KKK 


x REWIND CASSETTE OPERATION 


REWIND1. 
MOVE SPACES TO OUTBUF. 
MOVE RWND TO OUTBUF. 
MOVE 12 TO TATLH, 
PERFORM SENDING-MEDIUM,. 
PERFORM RETURN=-SENDING. 
END-REWIND1. 
FO IOI I tO tk kk kk 


* PISPLAY AN ERROR OPTION MESSAGE 


ER ROP Ts 

DISPLAY "“*** OPTION ERROR &xe" YPON CONSOLE. 
FND-ERROPT. 
FIN. 

DISPLAY "***kEND OF TEST***" UPON CONSOLE. 

SE OR: RUNS 


APPENDIX E 


CNC and QMA 


rotates te. trate! 


I 
COMMANDS & RESERVE 


cakeee 


The names reserved for CNC and QMAINT syntax may not appear as user values 
when either utility is run. 


The H_CNC utility uses NDL (network description language) commands but its 
reserved syntax is annotated as CNG 


Lists of the commands available for H_CNC and H_QMAINT utilities are included 
as reference to the explanatory text of reserved names that follow 


The 3 categories of reserved names are, 


- Command names, introducing the respective commands for the utility 
« Keywords which can be further classified as, 

- mandatory 

- optional 
- Arguments, appearing as values for keywords. 


NDL COMMANDS 


COMM defines a comment. 


COMM "String"; 


DCTAP identifies the version of the VCAM subsystem 


DCTAP name | SIMU = } : | 


GENCOM| describes the environment in which the network is to function 


GENCOM name . BATCHNB -| : al BIBFSZ | || DABFSZ = jase 
n nnn nnonn 
* Al NBBTBF = nnn | » NBDABF = nnn 
_470 _So 470 
[ anes - nnnn |: meroee -} nnnn dE a ea nnnn | 


ngage 
» OLMBRK = yx > SYSLOG |; 
defines the characteristics of the communications line 
LINE LNnn [,BKMOD ][, CGINS = nnn ][, cLosE][, cLv =n][, epx JL, ERcAP] 
[, ININS = nnn J[, LINPLG ][, NAUCDE ][, PADNB = nn J[, PARITY =n] 


a | /nnnn/ } ae | i RTCNT = nn 


[,seeeo—]].ser-}24 [ssn] [some [SPrTY [Pe err] [ rote ene] ; 


QUEUE defines all queues, program and terminal queues, used by the network. 


CTLRST NUMBLE=nnn 
QUEUE name |,BREAK }||,CLOSE}], >) NUMREC=nnnnn ? I], SHARE | . owas 
RESTART QCPOOL 


: KEY = password] » MAMNB = 


[,poutrst = (an[,nn]. +) | »>PRIRA= 


STATN]| defines a station attached to a polled line 
STATN name, Station-index [ .cxose ] ; 


TERMNL! defines the characteristics of the terminal. 


terminal-type 


TERMNL name, TYPE = SLAVE 


» STYPE = subtype [ app = “nh 
\ NL 

ES GN = nane]| ,avrolf, BLOCKING | E cose ||, conrrot , IM =4 MK 
UN 


[ LINELG = ona, LLENGTH = nnn |, NBLOCKS = nnn : OM = 


_\8o | _\ropase 
sexx = so sysneap =} ehh I 


QMAINT COMMANDS 


COMM defines a comment. 


PRINT prints the contents of one or more queues in the network. 


PRINT name [ ,name } eee 


| PURGE} | purges all or part of the messages currently in a queue. 


ALL | ; 


FURGE names } NUMBMSG = nnnnn 


QSTATUS| lists status and generation parameters of one or more queues. 


. name name | ee. 
QSTATUS si [ name 


SEND sends user-defined messages to queues. 


SEND name EE ~'end-of -message-string" | LENGTH = moan H 


STATUS continues or suspends processing of QMAINT commands on error. 


EVEN 
STATUS «, ONLY 3 
RESET 


ADD 
ASCII 


ASSIGN 
AUTO 
BATCHNB 
BKMOD 
BLOCKING 
BREAK 
BTBFSZ 
BIT* 
BTT 7300 
CAS 
CCINS 
CLOSE 
CLV 
COMM 
CONTROL 
CPU 

CRT 
CTLRST 
DABFSZ 
DCTAP 


* generic classification of terminals should also be considered reserved. 


SYNTAX SUMMARY 


DSK 
DTU* 
DTU7170 
EPX 
ERCAP 
GENCOM 
HL* 
HL6 1 
HL6 2 
HL64 
HL66 
IM 

IN 


KB 

KCT 
KDS* 
KDS7255 
KEY 
KPR 


CNC Reserved Syntax 


LINE 
LINELG 
LINPLG 
LLENGTH 
LN 
MAMNB 
MK 
MTS* 
MTS7500 
NAUCDE 
NBBTBF 
NBDABF 
NBLOCKS 
NL 
NUMBLK 
NUMREG 
OLIV* 
OLIV318 
OM 
OPER 


OU 
PADNB 
PARITY 
POLLIST 
PRIRA 
PRT 
QCBLKSZ 
QCPOOL 
QDBLKSZ 
QLIN 
QRRO 
QUEUE 
RESTART 
ROF 
RTCNT 
SBKLG 
SHARE 
SIMBRK 
SIMU 
SLAVE 


SPEED 
SPN 
SPTTY 
SSR 
STATN 
STYPE 
SYSHEAD 
SYSLOG 
TC* 
TC349 
TC380 
TCTNM 
TCV* 
TCV 260 
TERMNL 
TILEN 
TN*¥ 
TN300 
TN1200 
TOLEN 
TTU* 


QMAINT Reserved Syntax 


LENGTH 
NUMBMSG 
ONLY 
PRINT 


PURGE 


QSTATUS 
RESET 
SEND 
STATUS 


TTU8124 
TTU8126 
TTU8221 
TTY* 
TTY33 
TTY35 
TTY37 
TTY38 


VIP* 
VIP765 
VIP775 
VIP785 
VIP7100 
VIP7200 
VIP7700 
VIP7760 
VTE* 
VTE2820 


Reserved 
Word 


ADD 


ASCII 


ASSIGN 


AUTO 


BATCHNB 


BKMOD 


BLOCKING 


BREAK 


BTBFSZ 


CAS 


CCINS 


CLOSE 


Category 


optional 


argument 


optional 


optional 


optional 


optional 


optional 


optional 


optional 


argument 


optional 


optional 


keyword 


keyword 


keyword 


keyword 


keyword 


keyword 


keyword 


keyword 


keyword 


keyword 


CNC Reserved Syntax 


Explanation 


parameter of TERMNL command specifying the 
hardware address of a "'compatible'! terminal in 
the form of a 2-hexadecimal digit enclosed 
within quotation marks. 


defines the ASCII translation table for the 
keyword TCTNM optional to the LINE command. 


parameter of TERMNL command dedicating the 
terminal to a program queue or to the TDS 
versione 


parameter of TERMNL command for automatic log-on 
of a receive-only or master terminal. 


parameter of GENCOM command specifying the 
maximum number of batch entry processes that can 
be connected simultaneously to TDS. 


parameter of LINE command applicable only for 
TTY terminals equipped with the BREAK key. 


parameter of TERMNL command for generating a 
new-line or carriage-return/line-feed before the 
Start or after the end of line, respectively. 


parameter of QUEUE command applicable only to 
program queues on which the MCS COBOL 
application will receive control messages. 


parameter of GENCOM command specifying the size 
in bytes of each unit forming the BINS buffer 
pool used during I/O transfers. 


defines the terminal subtype as the ''cassette 
handler" for the keyword STYPE mandatory to the 
TERMNL command. 


parameter of LINE command specifying the number 
of DLE characters to be inserted after a control 
character activating a mechanical function. 


» parameter of LINE command specifying that BINS 
must not initialize traffic over the line 
until an "RT LNnn'' command is issued. 


+ parameter of QUEUE command specifying that the 
queue is initially disabled until the first 
application enables it, cf. ENABLE verb. 


CNG Reserved Syntax 


(continued) 
Reserved Categor Explanation 
Word Bory P 2 
CLOSE + parameter of STATN command specifying that 
continued... BTNS must not poll the station until an 


"RT xxxx'' command is issued, where xxxx is the 
name of the station. 


+ parameter of TERMNL command specifying that 
BTNS must not initialize traffic to the 
terminal until an '"'RT xxxx' command is issued, 
where xxxx is the name of the terminal. 


CLV optional keyword parameter of LINE command specifying the code 
level to be used in line transmission. 

COMM NDL command name introduces the COMM command. 

CONTROL optional keyword parameter of TERMNL command specifying that the 


log-on procedure for the terminal is subject to 
verification against the system catalog. 


CPU argument defines the terminal subtype as the "central 
processor unit" for the keyword STYPE mandatory 
to the TERMNL command. 


CRT argument defines the terminal subtype as the ''screen" for 
the keyword STYPE mandatory to the TERMNL command. 


CTLRST optional keyword parameter of QUEUE command applicable to terminal 
disk queues for "roll-back''. 


DABFSZ optional keyword parameter of GENCOM command specifying the size in 
bytes of each unit forming the VCAM buffer pool. 


DCTAP NDL command name introduces the DCTAP command. 


DSK argument defines the terminal subtype as the "disk(ette) 
drive'' for the keyword STYPE mandatory to the 
TERMNL command. 


EPX optional keyword parameter of LINE command applicable only for 
TTY37 type terminals (fully duplex) specifying 
that echoplex transmission is to be used. 


ERCAP optional keyword parameter of LINE command applicable only for 
TTY terminals specifying the "erase!'' capability 
by the use of the "back slash" or "reverse 
slant'' character (\). 


GENCOM NDL command name introduces the GENCOM command. 


CNC Reserved Syntax 


(continued) 


Reserved 
Word 


HL61 


HL6 2 


HLO4 


HL66 


iM 


IN 


ININS 


IOF 


KB 


KCT 


KEY 


LINE 


Category 


argument 


argument 


argument 


argument 


optional keyword 


argument 


optional 


keyword 


argument 


argument 


optional 


argument 


keyword 


keyword 


NDL command name 


Explanation 


defines the L64 processor as a BSC terminal for 
the keyword TYPE mandatory to the TERMNL command. 


defines the L62 processor as a BSC terminal for 
the keyword TYPE mandatory to the TERMNL command. 


defines the L64 processor as a BSC terminal for 
the keyword TYPE mandatory to the TERMNL command. 


defines the L66 processor as a BSC terminal for 
the keyword TYPE mandatory to the TERMNL command. 


parameter of TERMNL command specifying the 
format of input data passed from the terminal to 
the MCS COBOL application. 


defines the number of actions to have input 
priority on a line for the keyword PRIRA 
optional to the LINE command. 


parameter of LINE command applicable only for 
synchronous line procedures specifying the 
number of SYN characters sent before each 
message to allow for synchronization. 


name declared for "Interactive Operation 
Facility'' in DCTAP command, defining the 
appropriate version of the VCAM subsystem 


defines the terminal subtype as the "keyboard" 
(input capability) for the keyword STYPE 
mandatory to the TERMNL command. 


defines the terminal subtype as the "keyboard 
with screen'! for the keyword STYPE mandatory to 
the TERMNL command. 


parameter of GENCOM command specifying the 
password used by MCS COBOL applications to 
enable checking by MAM. 


defines the terminal subtype as the "keyboard 
with printer" for the keyword STYPE mandatory to 
the TERMNL command. 


introduces the LINE command. 


CNC Reserved Syntax 


(continued) 


Reserved 
Word 


Category Explanation 


LINELG optional keyword parameter of TERMNL command specifying the 
physical line length in characters as a 
2-decimal digit. 


LINPLG optional keyword parameter of LINE command specifying linear 
polling for a multipoint line; does not apply 
to the TTY line procedure. 


LLENGTH optional keyword parameter of TERMNL command specifying the 
number of characters in the logical terminal 
line size. 


mandatory keyword parameter of LINE command qualified by a 
2-decimal digit defining the line within the 
network. 

optional keyword parameter of GENCOM command specifying the 


maximum number of MCS COBOL application 
processes that can be concurrently executed. 


argument defines the format of input data passed from the 
terminal to the MCS COBOL application as "mark 
mode'' for the keyword IM optional to the 
TERMNL command. 


NAUCDE optional keyword parameter of LINE command applicable for all 
terminals if the line is declared "switched" in 
the SRST inhibiting the ring indicator detection 
thereby making the line unavailable, 


NBBTBF optional keyword parameter of GENCOM command specifying the 
number of units in the buffer pool used by BTNS 
to service terminals sending to and receiving 
from queueS. 


NBDABF optional keyword parameter of GENCOM command specifying the 
number of units in the VCAM buffer pool used by 
BINS for sending messages to terminals connected 
to VCAM subsystems. 


NBLOCKS optional keyword parameter of TERMNL command specifying the 
number of logical lines in each message to be 
sent to the terminal. 


argument - defines the format of input data passed from 
the terminal to the MCS COBOL application as 
"normal mode" for the keyword IM optional to 
the TERMNL command. 


E-08 


CNC Reserved Syntax 


(continued) 


Reserved 
Word Category Explanation 

NL - defines the format of output data passed from 
continueds ee the MCS COBOL application to the terminal as 


"normal mode" for the keyword OM optional to 
the TERMNL command. 


NUMBLK optional keyword parameter of QUEUE command specifying the number 
of core blocks to be used as the memory queue 
pool. 

NUMREC | optional keyword parameter of QUEUE command specifying the number 


of blocks to be used as the disk queue file, 
thereby setting the ceiling of disk file extent. 


OM optional keyword parameter of TERMNL command specifying the 
format of output data passed from the MCS COBOL 
application to the terminal. 


OPER keyword reserved name declared for the network control 
terminal in the TERMNL command having restricted 
characteristics. 

OU argument defines the number of actions to have output 


priority on a line for the keyword PRIRA 
optional to the LINE command. 


PADNB optional keyword parameter of LINE command applicable only for 
TTY terminals specifying the number of PAD 
characters sent at the end of each output 
message in order to avoid data loss in the case 
of turn-around on reception. 


PARITY optional keyword parameter of LINE command specifying the check 
on parity for input. data. 


POLLIST optional keyword parameter of LINE command applicable only if the 
line (with the exception of TTY line procedure) 
is declared multipoint in the SRST specifying 
the order in which stations are to be polled. 


PRIRA optional keyword parameter of LINE command specifying 
« the number of actions having either input or 
Output priority 
- the order in which terminals connected to MCS 
COBOL applications using output queues are 
scanned. 


CNC Reserved Syntax 


(continued) 


Reserved 


Word 


QCBLKSZ 


QCPOOL 


QDBLKSZ 


QLIN 


QRRO 


QUEUE 
RESTART 


Category 


argument 


optional keyword 


optional keyword 


optional keyword 


argument 


argument 


NDL command name 


optional keyword 


optional keyword 


optional keyword 


Exp lanation 


defines the terminal subtype as the "printer" 
(output capability) for the keyword STYPE 
mandatory to the TERMNL command. 


parameter of GENCOM command specifying the size 
in bytes of each core block used to generate 
the core queue pool. 


» parameter of GENCOM command specifying the 
number of core blocks of the core queue pool 
to be shared by all queues qualified by the 
QCPOOL option in their respective QUEUE 
commands, see below. 


» parameter of QUEUE command defining the queue 
aS a memory queue which is to share the core 
queue pool reserved by the QCPOOL parameter in 
the GENCOM command. 


parameter of GENCOM command specifying the block 
size in bytes of the disk queue file used for 
Saving messages. 


defines linear scanning of output queues for the 
keyword PRIRA optional to the LINE command. 


defines round-robbin scanning of output queues 
for the keyword PRIRA optional to the LINE 
command. 


introduces the QUEUE command. 


parameter of QUEUE command applicable to all 
disk queues in order to enable "roll-back" for 
"step abort" or ''system crash" conditions, 


parameter of LINE command specifying the number 
of retries to be attempted in case of a 
transmission errore 


parameter of TERMNL command applicable only to 
the BSC line procedure for specifying the sub- 
block size in characters to be generated by BINS 
when transmitting a character string. 


2 A TAO A SE OC ERE 


Reserved 
Word 


SIMBRK 


SIMU 


SLAVE 


SPEED 


SPN 


SPTTY 


SSR 


STATN 


STYPE 


SYSHEAD 


SYSLOG 


optional keyword 


optional keyword 


optional keyword 


argument 


optional keyword 


optional keyword 


argument 


optional keyword 


NDL command name 


mandatory keyword 


optional keyword 


optional keyword 


CNC Reserved Syntax 


(continued) 


Explanation 


parameter of QUEUE command applicable only for 
program queues allowing more than 1 MCS COBOL 
application to share the same queue in order to 
establish interjob communication. 


parameter of GENCOM command specifying a 
character string as a break qualifier in the 
form of up to 3 alphanumeric characters enclosed 
within quotation marks. 


parameter of DCTAP command specifying 

- the number of simultaneities of the declared 
TDS generation 

- the maximum number of terminals that can be 
simultaneously connected to IOF or ROF VCAM 
subsystems. 


defines the terminal type as a slave to a master 
terminal previously declared for the keyword 
TYPE mandatory to the TERMNL commands 

not applicable to TTY terminals. 


parameter of LINE command applicable only for 
terminals in asynchronous transmission defining 
the line speed as a single alpha-character code. 


parameter of LINE command applicable only for 
terminals in asynchronous transmission 
specifying the number of "stop" bits sent after 
each character. 


defines the standard TTY translation table for 
the keyword TCTNM optional to the LINE command. 


parameter of LINE command specified according to 
modem type and line speed. 


introduces the STATN command; 
not applicable to the TTY line procedure. 


parameter of TERMNL command specifying the 
terminal subtype in the case where the I/0 
capability of the terminal type is to be altered. 


parameter of TERMNL command specifying the 
character string used to precede any system 
message sent by the network control terminal. 


parameter of GENCOM command specifying that every 
system message sent by BTNS is to be logged in 
order to be printed out at the end of CNC session. 


CNC Reserved Syntax 


(continued) 


Reserved 


Word Category Explanation 


optional keyword parameter of LINE command applicable to the TTY 
and BSC line procedures allowing selection of 
a translation table other than the standard one 
defined for the line procedure. 


NDL command name introduces the TERMNL command. 


optional keyword parameter of LINE command specifying the "time- 
out" value used by the URP to control 
initialization or disconnection of the modem 


argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


TN1200 argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


optional keyword parameter of LINE command specifying the "time- 
out'' value used by the URP, 
« when polling a buffered terminal 
« when timing the interval between characters 
from an unbuffered terminal. 


TTU8124 argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


TTU8126 argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


TTU8221 argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP synchronous line procedure. 


argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


CNC Reserved Syntax 


(continued) 


Reserved 


Word Category Explanation 


Live 


igi 46 


LIY3¢6 


TWA 


TYPE 


UN 


VIP765 


VIP775 


VIP785 


VIP7100 


VIP7200 


argument 


argument 


argument 


optional keyword 


mandatory keyword 


argument 


argument 


argument 


argument 


argument 


argument 


argument 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


parameter of QUEUE command applicable only for 
program queues to enable dialog between the 
application and the terminal. 


parameter of TERMNL command defining the type of 
standard terminal specific to the line procedure. 


» defines the format of input data passed from 
the terminal to the MCS COBOL application as 
"unedited mode"! for the keyword IM optional to 
the TERMNL command. 


- defines the format of output data passed from 
the MCS COBOL application to the terminal as 
"unedited mode" for the keyword OM optional to 
the TERMNL command. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP asynchronous line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP synchronous line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP synchronous line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the TTY line procedure. 


defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP synchronous line procedure. 
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CNC Reserved Syntax 


(continued) 


Reserved 
Word 


Category Explanation 


VIP7760 argument defines the respective terminal for the 
keyword TYPE mandatory to the TERMNL command; 
applicable to the VIP synchronous line procedure. 


QMAINT Reserved Syntax 


Reserved : 
Word Category Exp lanation 
ALL optional keyword | parameter of PURGE command specifying that all 
messages in the queue are to be destroyed. 
COMM QMAINT command name | introduces the COMM command. 
ENDMSG optional keyword parameter of SEND command specifying the 


"marker'' as a string of up to 5 alphanumeric 
characters used after the message text as a 
delimiter. 


EVEN optional keyword | parameter of STATUS command specifying that only 
the following QMAINT command is to be processed 
when an error occurSe 


LENGTH optional keyword parameter of SEND command specifying the length 
of the message text in characters to be sent to 
the queue. 


NUMBMSG optional keyword parameter of PURGE command specifying the number 
of messages in the queue to be destroyed. 


ONLY optional keyword parameter of STATUS command specifying that the 
following commands are to be executed if no 
error has occurred. 


PRINT QMAINT command name | introduces the PRINT command. 

PURGE QMAINT command name |} introduces the PURGE command. 

QSTATUS QMAINT command name } introduces the QSTATUS command. 

RESET optional keyword parameter of STATUS command for resetting the. 
error count to zeroe 

SEND QMAINT command name | introduces the SEND command. 

STATUS QMAINT command name |} introduces the STATUS command. 
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APPENDIX F 


COMMUNICATIONS OPERATOR COMMANDS 


Communications operator commands comprise 

» Network control commands which can be entered on the system console 

+ Terminal operator commands which are shown prefixed with the default break- 
qualifier $*$. 


NETWORK CONTROL COMMANDS 
For detailed explanation, see Communications Network Control Terminal Operations 


Manual. 


The list of available commands for the network control operator or the GCOS 
system operator are, 

- BT broadcast telecom 

- DT display telecom 

- HT hold telecom 

- MTE modify terminal edit 

« MTL modify telecom line 

- MTP modify telecom poll 

- MTT modify telecom terminal 

« RDY ready 


«RT release telecom 
SL start telecom 
ec LE terminate telecom 


TERMINAL OPERATOR COMMANDS 


For detailed explanation, see Terminal Operations GCOS Manual. 


The break-qualifier is declared at CNC generation by the SIMBRK parameter of the 
GENCOM command, see Section V. 

If the SIMBRK parameter is omitted, then the default break-qualifier is $*$. 

In the list following, the default break-qualifier is used to distinguish the 
commands. that are applicable to the terminal operatore 


The list of commands for the terminal operator are, 
- BRK break 

- BT broadcast telecom 

» DIS’ disconnect 

» DT display telecom 

- HM halt message 

- MTE modify terminal edit 

« RDY' ready 

« RM resume message 


COMMUNICATIONS OPERATOR COMMANDS 


DIS 


MTE 


: break 


sends a "break" signal for log-on initiation or to an application. 


$*$BRK 


: broadcast telecom 


sends a message to destinations declared by the appropriate operands. 
$*$BT terminal message-text 


program 
program-queue 
terminal 

ALL 


BT message-text 


: disconnect 


disconnects the terminal from the application. 


HOLD 
*$DIS 
P*SDT STRONG 


: display telecom 


displays the status of the component declared by the appropriate operand. 


program- queue [ stronc | 
$*ODT QUEUE 
STRGNG 


line [stron] 
program [stronc] 
program-queue [STRONG ] 


DT | ) QUEUE 
station 
: QUEUE 
terminal es 
halt message 
halts delivery of the message to the terminal. 


$*$HM 


hold telecom 
inhibits the component declared by the appropriate operand. 


line 
program-queue 
station 
terminal 


HT 


modify terminal edit 


modifies data format sent from or received by the terminal. 


SkSMTE BLOCK sat wii ae nea (power 
a y * 
| NBLOCK k NG j onoRM J 
; BLOCK line-length()block-size TMARK \ oneDT 
MTE terminal NBLOCK a ee INEDT | ONORM 
INORM 


MTT 


[RT | 


COMMUNICATIONS OPERATOR COMMANDS 
| continued 


: modify telecom line 


modifies the functionality of a line or makes available maintenance 
facilities for the line. 


\ input-timecue{ Jourpue timeout} }read/wrize-ratof Speed \ 
* * * 
ae line \ TRACE 
INTRACE ( 
TRACE ! 
NTRAGCE 
: modify telecom poli 


modifies the polling list for a line from the "start" of the list 
indicated in the command. 


, 1 : ; 
MTP line {= station-name-1i/.../station-name-n 
Start: 


: modify telecom terminal 


modifies the characteristics of a terminal. 


terminal-queue-2 ALTER 


terminal-queue-1 NALTER 


MTT program 
terminal < program-queue ? 
NASGN 


: ready 


resumes transmission on a VIP terminal after a page overflow condition 
has set the "'busy'' state of the terminal. 


$*$RDY [STRONG | 
rby [ stRonG ] 


> resume message 


resumes delivery of the message to the terminal. 


$*$RM a 


: release telecom 


releases the component declared by the appropriate operand. 


line 
program-queue 
station 
terminal 


RT 


: start telecom 


starts a telecommunications seSsioOn 


ST 


: terminate telecom 


causes the telecommunications session to "shut-down''. 


TT [ stron | 


APPENDIX G 


CNC SYSOUT & QMAINT SYSOUT 
REPORTS 


CNC SYSOUT REPORT 


The information in the CNC sysout report comprises, 
- Input to H_CNC, iee., NDL commands generating the network 


- Output from H_CNC in terms of: 
- NDL error messages, see Appendix C 
- hardware and firmware parameters related to components constituting the 
network declared 
- sizes of tables and buffers. 


The purpose of the report is to enable the user to optimize the network and to 
tune its performance. 


CNG Sysout Report Structure 


header line 


CNC header banner 


header line 


NETWORK DEFINITION 


header line 


FIRMWARE PARAMETERS 


header line 


SUMMARY 


Header Line 


The header line appears as the first line of the CNC SYSOUT report and has the 
Standard format defined for any GCOS64 utility. 


CNC 
INA 
X14,1 
CNC L2 
—~Y TELF 
~) Coyuntt 
7) AnMTN 
— ] 19239215 
FF2 166 1978 
eae? aay 
time & date 
of execution 
project name 
(from $JOB) ee ae 
billing name RENEE ROre 
(from $JOB) 
user name 
(from $JOB) 
job name 


(from $JOB) 


job & step number 
of execution 


name & version number 
of CNC utility 


CNC Header Banner 


The CNC header banner follows the standard GCOS64 utility program header format: 
kkk hkkkke we kkk kkk kkk kkk k kakkhkhk kkk kkk kak ki kkk ke kak kk kkk kkk kk kkk kkk 
Rh kkkk kkk kha kk ke kkk kkk kkkkk ake kkikk kk kk kkk kkk kh kkkh kkk kh kk hkkk kk kik 


e 3°08 L464 ve 
ik Cc NC > 
* VERSTING ANAL DATED: SED 37,1977 * 


Re EXFCUTIONRE PORT Akaka aaa aK RK KKK kkh ahh hhh kkk kkk kk kkk kk kik 
eee K KKK KKKKeK KKK KKK KKK kek KKK Kh Khe kh kh hk kh kk kaka kk 
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Network Description 


The report contains the listing of the NDL commands provided by the user and 
any NDL error messages, if any, as defined in Appendix CG. 


See "Examples" later in the section. 


Firmware Parameters 


Each line declared by the NDL LINE command is listed with the following infor- 


mation, 


. SRST (system resource and status table) parameters defined during the firn- 
ware SRST generation thru RESOURCE cards, namely, 
- the line number . 
-. the UCLA (universal communications line adapter) of the DCC (data com- 
munications controller) to which the line is attached 
- the IURP or URP to which the UCLA is attached 


» TLT (terminal and line table) as loaded by BINS when initializing the line 
in question, containing the following, 
- the hardware parameters as defined during the IURP or URP firmware gen- 
eration 
- the software parameters in the LINE command which are, 
° implicitly defined by their default values 
° explicitly specified by the user thru keywords or parameter values 


The display format is as follows: 
LINE © LND2 ~e—SRST name of the line also declared in the NDL LINE command 


TYPE ¢ 


TTY : 


CONNECTED TO 3: 


URP 


TTY SVA 


line procedure as 
defined in RESOURCE 
card at SRST generation, 
of the following values: 


Teletype 


: VIP asynchronous 
: VIP synchronous 


BSG 


174999997 99846299 593739493 ANIZIRZRA—m 


: UCT1 SVA 


external name of IURP/URP to which 
the line is connected as defined by 


PE WOO OL 3 


Software Visible Attributes 
defined in RESOURCE card at 
SRST generation, giving the 
hexadecimal image of the 

TLT for the line concernede 


hexadecimal image of 
TLT for the line 


eae arose S 


Software Visible Attributes 
for IURP/URP. 


the RESOURCE card at SRST generations 


UCLA 


fexternal name of UCLA (DCC) to which 


the line is connected as defined by 


© CAV1 SVAM 


: BE De oe wk 


Software Visible Attributes 
for UCLA. 


the RESOURCE card at SRST generation. 
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Summary 


The display format is as follows: 


TOTAL NUMBER OF MESSAGES = Asc accumulated number of messages of 


ND_ ANALYSIS FRROR SUMMARY 
Sats 1, 2, 3 and 4, 


VARLOF WARNINSS SEV.1 = 3 

V3R.OF WARNINGS SFv.2 = 4 ¥ ee , 
WSR OF ERRORS SEY.3 = 7 —» individual count for each severity 
NAP OF FRRORS SEV.4 = 4 


SITE: NET——site-name as defined by the NDL GENCOM command 


NETWORK SUMMARY 


DECLARED LINECS) = ?—#:total number of lines declared by the 
respective LINE commands including VIP 
lines 

LINES WITH SIMU. = 2 ~e——- total number of VIP lines declared 


DECLARED STATIONCS) = 7 —®total number of stations declared by the 
respective STATN commands 
DECLARED TERMINAL CS) 1§$—mtotal number of terminals declared by 
[ene respective TERMNL commands 
CORE QUEUECS) 7 total number of declared memory queues, 
ieee, QUEUE commands specifying NUMBLK 
or QCPOOL option 
DISK QUFUE(S) 2 total number of disk queues, iee., QUEUE 
| commaride specifying NUMREC or no option 
TOTAL DEC. QUEYE CS) = 9—m total number of all queues declared, 
li. es, memory and disk queues 


DECLARED TAP(S) 5 


total number of VCAM simultaneities as 
defined by the algorithm, 


ZTDS + TSIMU 


where TDS = number of TDS terminals 
SIMU= SIMU values specified in 
DCTAP commands for IOF and 
ROF 
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queue file information will only appear 
if disk queues are defined in NDL deck 


EFN = “W"QUEUE external name of the queue file as 
defined thru the $ASSIGN card provided 
with the CNC JCL statements 


MENTA = (12 name of the disk medium containing the 
faaetie file 


5S CYL. ~—— size of queue file in number of cylinders 


QUZJYES FILE IS | 


N 


SIZE 


TABLES AND BUFFERS SIZES 
CDECIMAL VALUES IN BYTES) 
NETWORK TABLES = 3729 ~«—size of the BINS network table (1) 


3TNS SUFFER POOL 834) ~— size of the BINS buffer pool 


VCAM BUFFER POOL = 12823 —«— size of the VCAM buffer pool 


WAM TABLES R897 «— size of MAM tables (1) 


CORE QUFUES POOL 750) «— size of memory queue pool 


DISK QUFUES POOL 15745 ~— size of disk queue pool 


VCAM TARLES = 1795 ~#— size of VCAM tables (1) 
SEMAPHORES POOL = 1388 size of common semaphore segment (1) 


CNUMRER AND SIZE OF UNITS) 


on te ne es ae ee same information as above 
ed ee : 53 pein OF 4152 apes expressed in number and 
DUSK @.es.:= “S)° “UNITSOF: 390. S¥tES | 242o-08 Burter unite (2) 


(1) The tables (segments) are grouped as follows, 
- those automatically sized by CNC depending on the network generated 
- others specified by the user thru the parameters in the GENCOM command, 
such as BTBFSZ and NBBTBF. 


(2) In the case of the disk queue pool, the following algorithm applies as 
the pool contains other tables related to the queue file, such as the 
bit allocation map, used by MAM: 


size of disk queue pool > (number of units x size of unit) 
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Examples of Network Definition 


EXAMPLE 1 
ke k&kkkkkeek NETWORK DEFINITION wceerarerik 
GFNCOM NETS ,QCPOOL=20;7 
QUFUFS DECLARATION NFTWORK DECLARATION 


coum" LICAL TTY LINE", 
ComM " COPE QUEJES IN POOL "; LIVE LNT? SPEEDSHsERCAD,; 


QUE JE TTN? QACPOOL;: TERMNL TTI2 TY2E=VIP7100 STYPE=KCT, 
QUEUE TT14 QCPOOL, 

QUEUE ‘TTO2 QCPOOL, COMM " SWITCHED TTY LINE "- 

QUEUE SWCH aCPOOL- LIVE LNIQ7;2 


TERMNL TYO? TYPE=IN1200 STYPE=CPOR; 
COMM " CIRE QUFIES "F 
QUFUE 2°9G,/NUM3BLK=20; COMM ™ SHITCHED TTY LINE "; 

LIVE LND8 SPEEDZH FRCAP; 

TERYMNL SWCH TYPEHTN3CQ STYSEHKPRe 


COMM "LOCAL TTY LINE 
LINF LNITS ERCA?; 
TERMNL TITS sTYP=Z= TTU8B1I24 2STYPESKOR; 


The network is made up of 4 TTY lines of which 
- 2 are local lines, namely, LNO2 and LN16 
- 2 are switched lines, namely, LNO7 and LNO8. 


A speed of 300 bps, SPEED=H, has been specified for LNO2 and LNO8 since this 
is not the speed defined at firmware generation. 


The "erase" capability (\) is used for LNO2, LNO8 and LN16. As a result, the 
messages received on these lines will not exceed 134 characters (144 - 10), see 
ERCAP parameter in LINE command, Section V. 


The terminals connected over the lines may only communicate with a MAM applica- 
tion program thru the program queue PROG which is a memory queue of 20 blocks, 
each block having the default value of 70 bytes. 
Responses to the terminals are sent thru the memory queues named TTO2, TTO7, 
TT16 and SWCH which share a pool of 20 blocks, each block having the default val- 
ue of 70 bytes. 
The common memory pool is declared by 

» the QCPOOL parameter of the GENCOM command 

» the QCPOOL parameter of each QUEUE command sharing the pool. 


Since no OPER terminal has been declared, the system console is the network con- 
trol terminal. 


The TWU1003 type teleprinter must be declared with the "TTU8124" keyword. 
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EXAMPLE 2 
khekkekkehe NETWORK DEFINITION wert etkkne 


GENCOM NET2; 


DCTAP DECLARATIONS 


DCTA> TOF SIMUS3, 


NETWORK DECLARATION 


comm ™ LOCAL TTY LINE”? 
LIVE LNQ? SPEED SHSERCAP, 
TERMNL TT)2 Ty®£=VIP7100 STYPESKCT CONTROL, 


comm " SWITCHED TTY LINE “> 
LINE LNO7z 
TERMNL YT37 TYPE= IN1200 STYPESKPR CONTROL; 


cCoMM " SWITCHES TTY LINE "2 
LIVE LND® SPEEDSH FRCAP,; 
TERWNL SWCH TYSE=TN3INO STYPFHKPR CONTROL; 


CoMmM "LOCAL TTY LINE "3 
LIVE LN16 ERCA?? 
TERMNL TT1S-TY2=Z=TTU8I24 »STYPESKPR CONTROL? | 


The network declared is exactly the same as that generated in the previous exam- 
ple but the terminals are intended to work only with the VCAM IOF subsystem 


All the terminals are declared with the CONTROL option which is mandatory for 
connection to IOF. 


The IOF subsystem accepts 3 simultaneous connections as defined by the SIMU par- 
ameter of the DCTAP command. 
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EXAMPLE 3 


The network following is an extension of that given in Example 2. 


Terminals Lines Queues Application 
terminal program 


OPER < 


TTO2 CN te 


PEO co I 


SWCH 
10F 
TT16 <@ 


LN16 


VP2 


VP3 


CA3 


PR3 


VP4 


CA4 


Note : Only a sample number of queues is shown in the diagram 
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EXAMPLE 3 


kkekaxtenekex NETWORK DEFINITION eet etkk atk te 


SENC OM 


couy 
QUEUE 
QUEUE 


cow se 
QUEUES 
QUEUF 
QUEUE 
QUEUE 
QUE YE 
QUEUE 


coum " 
QUEUE 


NET RTBESZ=20C DARFSZ225) 

90°09. 279,975 3LKS7Z2215) 993. KS7239) 
MAMNB=? BATCHNR=3 

NSATBFH490 NPDABFHS3 SYSLOS? 


QJEUES DECLARATION 


DISK QUZJES "2 
INP2 RESTART; 
INP3- 


CORE QUEJFS IN POOL "> 
TTO7 QCPOOL; 
TT16 ACPOOL,s 
TTO2 QCPOOL; 
SW#CH QCPOOL- 
Vv>2 acPOOL-s 
VP4 acPOOL,s 


CORE QUEJES “2 
OK4 NUMSLK=20; 


DCTAP DECLARATIONS 


DCTA> TOS, 
OCTAP TOF SIMUS33 
DCTA> ROF SIMUST? 


G-09 


cowm . 
° NETWORK DECLARATION bi 


COMM ™ NETWORK CONTROL OPERATOR LINE "7 
LINE LN133 

STATN S1)101¢ 

TERMNL OPFERSTYPZEVIPZEOS sSTYPEZSKIOT CONTROL: 


COMM * LOCAL TTY LINE"; 
LINE LND2 SPEED EHS ERCAP, 
TERMNL TT)2 TYPE= VIP7100 STYPE®KCT CONTROLe 


Comm " SHITCHED TTY LINE "7? 
LINE LND7> 
TERMNL TTD7 TYPE= IN1200 STYPESKPR CONTROL: 


COMM " SWITCHED TTY. LINE "; 
LIVE LNO8 SPEEDZH ERCAP; 
TERYNL SAHCH TYP EZTN30O STYPE=KPR CONTROL? 


COMM "LOCAL TTY LINE "3 
LINE L415 ERCAPS. 
TERMNL TT16-TY°E= TTU812Z4 »STYPEEKPR? 


COMM " POLLED VIP LINE CSYNCHRONOUS) "3 

LINE LN94 RTCNT24 TOLEN=4 LINPL3-> 

STATN 8041413 

TERMNL VO1eTYPESVIP77S oSTYPERKCT os ASSIGNETDS sl ONTROL:? 
TERMNE: VP26TYPZEVIP7T7S oe STYPESKCT ASSIGNEE V2 2+ CINTRO_G 
STATN SOb2022 

TERMNL V9ZeTYPEZVIP 7700 oSTYPEZKCT cASSISNSTDS PAST? 
TERMNL PR3STYPESSLAVESSTYPESLAS: 

TERYNE CAS e+ TYPEZSLAVEsSTYPEEPRIT? 

STATN $043,633 

TERMNL VP4 TYPE=VIP7700 STYPE=KCT ASSIGN= INP3 AUTO; 

TERMNL DK4 TYPE=SLAVE STYPE=CAS; 
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EXAMPLE 4 


kkkkkkkkeee NETWORK DEFINITION tha kekk kek 


GENCOM NET RTBESZ=20C DAPFS7Z=25) 
QCPAONLERV,I09LKSZ=15) JoBLKS7=797 
NERTRFH40 MPDABEHS7 SYSLOG? 


caw 

. QUEUYFS DECLARATION 
COMM " DISK QUEFJES 3 
QUFUEF INP2 RESTART; 
QUEUE H64 CTLRST? 


COMM " CORE QUEJES IN POOL "7 


QUEUE TTO7 QCPOOLs 
QUEUJE TT16 ACPOOL; 
QUEUE TTN? Q2CPNOL-; 
QUFUE SWCH QCPOOL?; 
Ca" 
ie NCTAP DECLARATIONS 


DCTAP TOF SIMUE=23 
DCTAP ROF SIMU=13 


cows 
" NETWORK DECLARATION nies 


COMM " LOCAL TTY LINF"™; 
LINE LNO2 SPEED FHAERCAP, 
TERWNL TTI2 TY>E= VIP7100 STYPESKCT CONTROL, 


COMM " SWITCHED TTY LINE ", 
LINE LNO7; 
TERMN. TT7 TYPE= IN1200 STYPE=KPR CONTROL; 


Commu " SWITCHED TTY LINE 
LINE LNT8 SPEEXSH ERCAP; 
TERMNL SWCH TYPESTNUCN STYOEZKPR CONTROL, 


COMM "LOCAL TTY LINE ">; 


LIVE LNT4 ERCAP;? 
TERMNL TTTA, TYPES TIUB1I2Z4 ,STYPESKPR CONTROL? 
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CoMM * LEVEL 64 3SC LIVE "3 

LIVE LATS SSR? 

STATN SO51013 

TERYN, HS5G,TYPESHL 640STYPFECOULASSIGNEI ND 26 AITIS 


The network is an extension of that given in Example 2. 
The extension consists of a file transmission line, namely, 


« LNO5 used for a L64 to L64 file transmission under an MCS COBOL program 
control thru the disk queues named INP2 and H64 


In the case of the MCS COBOL program, the ''controlled restart" facility is used, 
iee., the CTLRST parameter is specified in QUEUE H64 command. 
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QMAINT SYSOUT REPORT 


The information given in the following example of a QMAINT sysout report is, 
- the JCL statements used when executing an H QMAINT session 


« the report of the execution comprising, 
- the effects of commands performed on the queues 
-~ the error summary of the H_QMAINT session. 


H_QMAINT executes actions on the queues as follows, 
« QI, Q5 and Q6, which are disk queues 


« Q2 and Q3, which are memory queues. 


A detailed explanation of the report for each type of QMAINT command performed 
is given in Section VI. 


The description of header lines and banner is the same as for those appearing 
in the CNC sysout report. 
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JCL Statements 


$JOB TST*#QMAINT 

sUSER=UNAME »-PROJECT=ADMINJBILLING=ADMINNe 

STEP HEQMAINT 

*SYSHLMLIBs 

ASSIGN H€CRs*QMAINTs 

ENDSTEP; 

SINPUT QMAINTATYPE=DATASSF, 

SEND Q1,ENDMSG="//FIN",LENGTH=160; 

AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAA 
AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA 
AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAAA 
AAAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA ; 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA i 
AAAAAAAA AAAAAAAAAAAAAAAAAA 
AAAAAAAA AAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAA 
AAAAAAAAA 
AAAAAAS—— 
// FIN 

SEND Q1,LENGTH=160; 

8BS888838 888888888 88888 8BBBBBBBBB8BB8B BS88B888B8R8BBB8BB BBB BBB2 
BBEBBBB88SBBS8BSBBBB BSBBBBBBBSBBBBBBBBBBRBBBEBBBBBBBBBB BBBBBBBB82 
8B8B8883888B888888883BBB8BB8BBBBBBBBBBBBBBBEBBBBBB BBBBBBBBBBBB2 
88888888888388888888888888888B888B888 88BBB BBB 8B8B8BBBBBBBBBB2 
BBBBB8B888BB8B88B888BS8BB88 BBBBBBB8BBBBBBBBB BBSBBBBBBBBBBBBBBBBBBB 
BBBB8B8B88 SBBBBBBS8BBBBB8BBBBBBBBBBBBBB 588888888888B85 8BB888B8BBBB868B 
BBS8BB88 BBBBBBBBBBSBBBBBBBBBB 3B83BB8B8C088888B8B88B BBBBBBBBBBBBBB 
BB8BS8BBS8BB8BB88BBBBBBSBBBBBy 8BBB888888883883B8B8BB BBB8BBBBBBBBBB 
BBBB8BB888 8B88BBB8B8BBB BBBBS88BBBB8888888888BBB8B8B8B8 8BBBB3B8888BBB 
BBBB8BB88 BBBBBBBB 88888888888888888883838B888888B 3BBBBBBSBBBBBB 
BB8B888B88BBB BBB88B8B8B8BB88B8BBB88B8B8BBB88888BBBB BBB BBBSBBBBBBBBBB 
b BBBBBBBSBBBBBBS888BBBBB8B8BBBBBB8B888BBBBB8 SBBBBBBBBBBBBB 
5B8BB888B888888888888B88888888B838885388 8888888 8B888BB38B8BBB 


AAAA111 
“<AAAAAAAAAA111 
AAAAAAAAAAAAA1114 
AAAAAAAAAAAAAAAAAA111 
AAAAAAAAAAAAAAAAAAAAAA 111 
AAAAAAAAAAAAAAA AAAAAAAAAAA11 1 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI1 
AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAT1 1 
AAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAA AAAAAAAAAA AAT 1 
AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA11 4 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA 111 


Q@STATUS *; 
PRINT *,; 

PRINT 21402-Q3; 
PRINT 24; 

PRINT Q5;7 

PRINT Q6;3 

PURGE 21/NUMBMSG=1; 
PURGE Q1/NUMBMSG=1- 
QSTATUS *; 

PURGE Q2sALL2 
QSTATUS Q1,4Q2; 
PRINT *3 

PURGE 21,NUMBMSG=12 
PURGE 23.4ALL3 

PURGE 24/NUMBMSG=3; 
PRINT Q32 
SENDINPUT; 

SENDJO32 


Execution Report 
SEND 21 ENDMSG="//FIN"-LENGTH=1603 


GUEUE NAHE 3 Q1 
MESSAGE STATUS 3: JK 
MESSAGE LENGTH ¢ 000166 


MESSAGE CONTENTS 3 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAATITAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


ASAAAAASARAAAAABAAAAAAAAAAAAAAAAASAAAAASAAAAAAANINI 


SEND Q1,/LENGTH=160;7 


QUEUE NAME 3: Q 
MESSAGE STATUS ¢ ; UK 
MESSAGE LENGTH ¢ 000160 


MESSASE CONTENTS 3 
B8SBS8SB3CUSSBBBESB8BBSBSBBB8B38BeBb3IBBSSBBSB3BBBBBBBBEBBB 
BSBB88BB36B8SRs0BRB3RBBBBBB23BB3BRBBBBBBBBBBBBSBBBBBBBBBBBB 
B8288388333383868832838B88838638 3339543388398 8883369838B82 


QSTATUS *, 


GUEUE NAME wi 
NUMBER OF COMPLETE MESSAGES 3: 000092 
NUHSER OF MESSAGES IN SEND PHASE 3: ozeney crore: 
NUMBER OF MESSAGES IN RECEIVE PHASE : 000006 
MAXIMUM NUMBER CF BLOCKS IN POGL : 032767 
NUMBER OF 3LOCKS USED FROM POOL : 000010 
PROGRAM QUEUE 

QUEUE ATTRIBUTES 3: DISK 
QUEUE NAME 3 Q2 
NUMBER OF COMPLETE MESSAGES : 000000 
NUMBER OF MESSAGES IN SEND PHASE ¢:. 000090 
NUMBER OF MESSAGES IN RECEIVE PHASE : oocooc 
NUMGER OF BLOCKS ALLOCATED TO THIS QUEUE : 00004G 
NUMBER OF BLOCKS USED FOR THIS QUEUE : o0000C 
PROGRAM QUEUE 

QUEUE ATTRISUTES : CORE 
QUEUE NAME : Q3 
NUMDER OF COMPLETE MESSAGES ; 000090 
NUMBER OF MESSAGES IN SEND PHASE : 0060990 
NUMBER OF. MESSAGES IN RECEIVE PHASE 3 o0ccoc 
NUMGER OF BLOCKS ALLOCATED TO THIS QUELE : 0000466 
NUMBER OF BLOCKS USED FOR THIS wJEVE 3 90C000 


PROGRAM QUEUE 
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PRINT *3 


QUEUE ATTRIBUTES 3: CORE 


QUEUE NAME : a4 
NUMBER OF COMPLETE MESSAGES : oo0coo0o 
NUMBER OF MESSAGES IN SEND PHASE : oogo00 
NUMBER OF MESSAGES IN RECEIVE PHASE : coococ 
MAXIMUM NUMBER OF BLOCKS IN POOL : 032757 
NUMBER. OF BLOCKS USED FROM POOL : c00090 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME : Qs 
NUMBER OF COMPLETE MESSAGES : 000006 
NUMBER OF MESSAGES IN SEND PHASE 3: 000000 
NUMBER OF MESSAGES IN RECEIVE PHASE : 000000 
MAXIMUM NUMBER OF BLOCKS IN POOL : 032767 
NUMBER OF BLOCKS USED FROM POOL : 000090 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME 3: Q6 
NUMBER OF COMPLETE MESSAGES : 000000 
NUMBER OF MESSAGES IN SEND PHASE : 00c000 
NUMBER OF MESSAGES IN RECEIVE PHASE : 000000 
MAXIMUM NUMBER OF BLOCKS IN POOL : 032767 
NUMBER OF BLOCKS USED FROM POOL : ooococ 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME ; Qi 
NUMBER OF COMPLETE MESSAGES : 0000902 
MESSAGE NUMBER 3 000001 
MESSAGE STATUS 3: OK 
MESSAGE LENGTH 3: 000160 


MESSAGE CONTENTS. : 

AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAARAAAAAAAAAAAAAAABAAAAA 
AAAAAAAAAAAAAAAAAAAAAA111 AAA AAAAAAAA AAAAA AAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI11 
MESSAGE NUMBER 3 000002 
MESSAGE STATUS OK 
MESSAGE LENGTH 000160 
MESSAGE CONTENTS °: 
BBB88888883888883888888883838683588BBBBB3BBBBBBBSBER88BB 
888888888888888888888B88B2 38888888888 888BBBBB88BB8 BBBBBB 
BBBBBBBB883888B8B88888888B88B 8888888 BBEBSBBBBBBBBBe 
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WUJEUE NAME 3 
NUT E 


ok: hE seer ee 


QUEUE NAME 3 
NUMBER. oF COMPEETE 


QUEUE NAME 3 
NUMBER OF COMPLETE 


QUEUE NAME 3: 
NUMBER OF COMPLETE 


QUEUE NAHE 3 
NUMBER OF COMPLETE 


PRINT 21,702,903, 


PRINT 


PRINT 


4 


tw 
mo 


ae 


QUEUE NAWE 3: 

NUMBER OF COMPLETE 
MESSAGE NUMBER 
MESSAGE STATUS 
MESSAGE LENGTH 3 
MESSAGE CONTENTS ¢ 


AAAAAAAAAAAAAAAAARAAAARABAAAAARK AAR AAAARAAAAAARAAAARBAA 
AKRAARASAAAAAARAAAAAAAAI11 ARAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 


a on Ot alt on ion Ed 


a6 
JGOGIO 


Q 
000092 
COOU0T 


SARARAABANSKALAAMASEAANKASRARAA CARA ANARAABARNAAT 1 


MESSAGE NUMBER 
MESSAGE STATUS 
MESSAGE LENGTH : 
MESSAGE CONTENTS ¢ 


PBB8ESBS838333BB3BERBBBBSBBBBBBHSBRBESSUSSBSBREBSBBSSBSEBBE 
SS5BB838B36BBBEB883BBBB8B2 BBBB8S8BBBBBSBBBBBSBBBBBBEBBBBBB 


~Cocove 
OK 
COC160 


63863383888888688388B88685828 35365333333888853338832 


QUEUE NAME : 
NUMBER OF COMPLETE 


QUEUE NAME 3 
NUMBER OF COMPLETE 


GUEUE NAME 3 
NUMBER OF COMPLETE 


QUEUE NAME 3 
NUMGER OF COMPLETE 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 
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q2 
oococo 


Q3 
CocGcac 


a4 
090000 


Qs 
090090 


PRINT ao, 


GUEUE NAME : Q6 
NUMBER OF COMPLETE MESSAGES : 000009 


PUFGE 21 -/NUMBMSG=1, 


QUEUE NAME 3; Q1 
NUMBER OF DELETED MESSAGES 000001 


PURGE 31/NUMBMSG=1; 


QUEUE NAME 3° Qi 
NUMEER OF DELETED MESSAGES 000001 


QSTATUS *, 


QUEUE NAME 3; Q1 
NUMBER OF COMPLETE MESSAGES : o00c00 
NUMBER OF MESSAGES IN SEND PHASE : 000000 
NUMBER OF MESSAGES IN RECEIVE PHASE : 000000 
MAXIMUM NUMBER OF SLOCKS IN POOL : 032767 
NUMBER OF 3LOCKS USED FROM POOL : 000002 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
GUEUE NAME : Q2 
NUMBER OF COMPLETE MESSAGES : 000000 
NUMBER OF MESSAGES IN SEND PHASE : 000000 
NUMSER OF MESSAGES IN RECEIVE PHASE. :_ 000000 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE : 000040 
NUMBER OF BLOCKS USED FOR THIS QUEUE : 000000 
PROGRAM QUEJE 

QUEUE ATTRISUTES : CORE 
QUEUE NAME : az 
NUMBER OF COMPLETE MESSAGES : 000000 
NUMBER OF MESSAGES IN SEND PHASE : 000000 
NUMBER OF MESSAGES IN RECEIVE PHASE 3: o0cooo 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE : 000040 
NUMBER OF BLOCKS USED FOR THIS QUEUE : 000000 
PROGRAM QUEUE 

QUEUE ATTRISUTES 3: CORE 


QUEUE NAME 3 Q4 


NUMBER OF COMPLETE MESSAGES : 006099 
NUMBER OF MESSAGES IN SEND PHASE : oyereverere 
NUMBER OF MESSAGES IN RECEIVE PHASE : oo0000 
MAXIMUM NUMBER OF BLOCKS IN POOL : C32767 
NUMBER OF BLOCKS USED FROM POOL : cooaoo 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME : as 
NUMBER OF COMPLETE MESSAGES : coccoo 
NUMBER OF MESSAGES IN SEND PHASE : eherereyere) 
NUMBER OF MESSAGES IN RECEIVE PHASE : cN0000 
MAXIMUM NUMBER OF BLOCKS IN POOL : 632757 
NUMBER OF BLOCKS USED FROM POOL : 000000 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME : a6 
NUMBER OF COMPLETE MESSAGES : oocaos 
NUMBER OF MESSAGES IN SEND PHASE : go000og 
NUMBER OF MESSAGES IN RECEIVE PHASE : ooo0ou0 
MAXIMUM NUMBER OF BLOCKS IN POOL : 032767 
NUMBER OF 3LOCKS USED FROM POOL : 000090 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 


PURGE 22-ALLe 


QUEUE NAME ¢ Qe 
NUMBER OF DELETED MESSAGES Q0G000 


QSTATUS Q1,Q2. 


QUEUE NAME : Q1 
NUMBER OF COMPLETE MESSAGES : arereserel® 
NUMBER OF MESSAGES IN SEND PHASE : 000ca) 
NUMBER OF MESSAGES IN RECEIVE PHASE 3 ooccoo 
MAXIMUM NUMBER OF BLOCKS IN POOL ¢ 032767 
NUMBER OF BLOCKS USED FROM POOL : a0a002 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : DISK 
QUEUE NAME ¢ Q2 
NUMBER OF COMPLETE MESSAGES 3 ooo00c 
NUMBER OF MESSAGES IN SEND PHASE : 900096 
NUMBER OF MESSAGES IN RECEIVE PHASE : 900000 
NUMBER OF BLOCKS ALLOCATED TO THIS QUEUE = 000040 
NUMBER OF BLOCKS USED FOR THIS QUEUE : ooccoo 
PROGRAM QUEUE 

QUEUE ATTRIBUTES : CORE 
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PRINT 


PURGE 


PURGE 


PURGE 


PRINT 


ky 


QUEUE NAME 3: 
NUMBER OF COMPLETE 


QUEUE NAME 3; 
NUMBER OF COMPLETE 


QUEUE NAME ° 
NUMBER OF COMPLETE 


QUEUE NAME : 
NUMBER OF COMPLETE 


QUEUE NAME ¢ 
NUMBER OF COMPLETE 


QUEUE NAME 3: 
NUMBER OF COMPLETE 


21 -NUMS3MSG=1;- 


QUEUE NAME 3 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 


MESSAGES 


NUMBER OF DELETED MESSAGES 


23-,ALL- 


QUEUE NAME ¢ 


NUMBER OF DELETED MESSAGES 


a4 ¢NUMBMSG=3, 


a3; 


QUEUE NAME 5 


NUMBER OF DELETED MESSAGES 


QUEUE NAME 3° 
NUMSER OF COMPLETE 


MESSAGES 
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Q1 
0cOCvo 


Q2 
000090 


Q3 


000000 


Le 
000000 
Qs 
000090 


Q6 
000C00 


Q1 
00000G 


Q3 
000000 


Q4 
O00CO0 


Q3 
Q00000 


ERROR SUMMARY 


Rea KA Kee Ke KKK KK 


ERROR 
*EKROR 
**x ERROR 
wee ERROR 


acO314 
@c¢0315 
ac0316 
ac0317 


SEVERITY 
SEVERITY 
SEVERITY 
SEVERITY 


00 
01 
O2 


0 3. 


TOTAL NUMBER OF ERRORS : oo00co00Gg0 
NUMBER OF ERRORS OF SEVERITY 1:0000G00000 
NUMBER OF ERRORS OF SEVERITY 2:090900000000 


ed ed 


NUMBER OF ERRORS OF SEVERITY 3:0000000000 
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APPENDIX H 


COMMUNICATIONS STATUS KEY CONDITIONS 


The CD communications description statements define the parameters required to 
interface with MCS, namely, 
- between MCS and the application, 
- ACCEPT :which makes available the current number of messages in a 
specified symbolic queue. 
- RECEIVE: which receives a message from a specified symbolic queue. 
- SEND :which sends a message to a specified symbolic output queue. 
» between MCS and the terminals, 
- DISABLE: which closes communications between MCS and the specified queue. 
- ENABLE :which opens communications between MCS and the specified queue. 


The status of this MCS COBOL interface is given by a set of status key codes, 
each uniquely defined by 2 alphanumeric characters denoting the status of each of 
the parameters, ieee, the ''x'' denotes the parameter has been specified. 


The parameters listed in the following table in alphabetical order are, 
e ACCEPT 

» DISABLE INPUT (with TERMINAL) 

- DISABLE INPUT (without TERMINAL) 

e DISABLE OUTPUT 

- ENABLE INPUT (with TERMINAL) 

- ENABLE INPUT (without TERMINAL) 

e ENABLE OUTPUT 

e RECEIVE 

e SEND. 


Status key codes from 9A thru 9E are only applicable if the appropriate program 
queue has been defined with the "BREAK" option. 


H-O1 


Communications Status Key Conditions 


ACCEPT (with COUNT) 
DISABLE INPUT (with TERMINAL) 
DISABLE INPUT (without TERMINAL 


Status DISABLE OUTPUT 
Key ENABLE INPUT (with TERMINAL) 
Code ENABLE INPUT (without TERMINAL) 
ENABLE OUTPUT 
RECEIVE 
SEND 


[00 _blalabebsalele[s| wo error deteccedy action completed 
20 [TTT TLL [af or nore destinations disabled, action comleced 
20 et txt |x| [xt | 1 or more queues/subquéues unknown*,no action taken 

i aeleotel ace: payer source unknown*,no action taken. 


x x} |x} no action taken for 1 or more destinations unknown* 
action taken for known destinations. 
data-name-4 (ERROR KEY) indicates known or unknown*, 
| 30 | | { |x| | |x] ]x] DESTINATION COUNT invalid, no action taken, 
| 40 | fx|x]xfx|xtx] | | password invalid, no.enabling/disabling action taken 
30 x| character count >length of sending field, no action 
taken. - 


x| partial segment with O character count or no sending 
area specified, no action taken. 


91 xX] message data not transferred to queue due to : 
unavailability of mass storage. 

92 x|xX{| mesSage data not transferred due to unavailability of 
memory Spaces 

93 x 


no data can be input from the terminal to the queue 


ae to which a DISABLE statement has been issued. 
PUTT searsntsncnsesereesc 
message Size exceeded, message truncated. 
5 TTL TL [ff | messase coo tong, eruncated co maxim size specifies 
TIT TTT] [ef nessese discarded due co queue allocation overflow 


identifier-2 (see SEND statement) # "0", "2" or "3", 


a ele message data not transferred due to I/O error on disk 
file. 


Communications Status Key Conditions 


(continued) 


ACCEPT (with COUNT) 
DISABLE INPUT (with TERMINAL) 
| | [DISABLE INPUT (without TERMINAL) 


Status DISABLE OUTPUT 
Key ENABLE INPUT (with TERMINAL) 
Code ENABLE INPUT (without TERMINAL) 
ENABLE OUTPUT 
RECEIVE 
SEND 


9A x BREAK has been detected, queue corresponding to 
| symbolic source has been disabled. 
x RVI has been detected, queue corresponding to symbolic 
source has been disabled. 
9C x terminal corresponding to symbolic source has been 
disconnected. 
Xx terminal corresponding to symbolic source has been 
connected. 


shutdown is announced, application is required to 
terminate. 


9 


tH 
ee 2 
Maetaast 
a 
ines 
el 
ed 
ace 
ae 
eee 


access to queue in conflict with JCL definition, or 
related terminal not logged on to application 


message not transferred, checkpoint should be taken 
before attempting further data transfers. 
applicable to queues with the CTLRST option. 
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APPENDIX I 


During a communications session, BINS gathers statistics to enable the user 
« to tune the network, see Section V 
- to control the traffic over each line and terminal. 


The BINS JOR listing consists of 
« system information 
+ system messages 
« Statistics. 


SYSTEM INFORMATION 
The following print-out is self-explanatory. 


JOBIO=BINS USEREBTNS PROJECTHESPERATOR RILLINZSEINSTALL RONZEXI973 


22233220 JOB EXECUTION LISTING FE3 14,5 1978 


-_owe we ww a 
warm evenw re wee wwraweoe newer awwo wren weer awew wre tmeoweerwrwwoanwwecereereuwewwewewer rer" 


LOAD MODIJLF = H_3BTINS (78/72 /15 152)9)) 
LIBRARY = SYS.,4L¥MLI8 
SHARED MODILF = H_S™1 
LIBRARY = SYS.HSMLIB 
SHARED MODULE = H_S™? 
LIRRARY = SYS.4SMLIB3 
22233231 STEP STARTED KPRTY=) 


SYSTEM MESSAGES 


The following 2 pages are a sample of system messages and commands exchanged 
during the session. 
The listing will appear if the SYSLOG parameter of the NDL GENCOM command has 
been specified. 
For details of system messages and commands, refer to 

« Communications Network Control Terminal Operations Manual 

« Terminal Operations GCOS Manual. 


CC21 
22.31 

* cc31 
~->22,31 
x CC)2 
-->272,31 
22251 
S| 

* cc)1 
-->272.,32 
* CCI2 
=->22.32 
2243? 
22.32 
22852 
22232 

* cc31 
~->72,32 
* cc32 
—-->?2.32 
CC33 
22.32 
-->22 .33 
CCI 
cc29 
CC3? 
cc1) 
~->22.32 
CCIR 
ccj9 
CC3?2 
cc1)2 
-->22.33 
CC33 
-->22,33 
~->22.33 
CC33 
-->27,34 
~->22.34 
CC33 
—->?9.34 
~->22.34 
CC33 
-->22.,35 
cC33 
-->72.,35 
cc1) 
-->22.,35 
CC33 


CANNOT BF OPENED REASON: FNABLE CP FAILED 


STARTED 
USER/PROJECT/3ILLINS» APPL? 
TT/TIA/TIA-TTI2 

PASSWORD?3; 

LL 

ACTIVATED FOR TTON2 ION FER 14,5 1 
ACTIVATED 
IDZUSER/PRIOJESCT/BILLING » APPL ? 
RTZIOF 
PASSWORD?9; 
H4 
ACTIVATED 
DEACTIVATED 
DEACTIVATED 
ACTIVATED 
IDsUSFR/PROJECT/BILLING » APPL ? 
RToRTIVS6IOF 

PASSWORD?23 

FF 

LOGGED 

ACTIVATED FIR IOF ON FEB 166 1 
$*SDT STRONG 

ACTIVE FOR IOF /TEM? US= 
NBLOCK 133/118 IN=N JUEN 
OM=715 IM=1% OF=0 

O MSGC(S) 1))% OF FREE SPACE 
$*$DT STRING 

ACTIVE FOR TTJ2 /TEW> US= TT 
NBLOCK 109/118 INEN QUEEN 
OM=8 IM21) OE2) 

O MSG(S) 137% OF FREE 
HELLO 

COMPLETED 

$*$8T MAIN HELLO 
HELLO 

COMPLETED 


OV FE3 
By USER 


156 1 


RT01 


SPACE 


$*$3T MAIV OLEASE MOUNT DISK C122 


PLEASE MOINT DISK C122 
COMPLETED 


$*$3T MAIN IS C122 WEDIA MOUNTED? 


IS €122 MEDIA MOUNTED? 
COMPLETED 

WAIT FOR 5 MINJTES PLEASE 
COMPLETED 

F* SDT PRIS AUEVE 

O MSGCS) 139% OF FREE 
*€DT TTI8B QUEUE 
INVALID NAME 


SPACE 


-->22.35 TTJ2 FeFNT TT15 AVUEVE 


cC1) TT16 O MSSCS) 133% OF FREE SPACE 
cc1) TT37 OQ MSGC(S) 137% OF FREE SPACE 
CC19 TT16 OC MSGCS) 133% OF FREE SPACE 


rT] sty eee eva ery fee 


cc1) TT)2 MSG(S) 133% OF FREE SPACE 
C€C17 SACH WS6(S) 13)% OF FREE SPACE 
CC1) PROG “SGCS) 133% OF FREE SPACE 


0 
0 
0 
CCO3 sT COMPLETED 
cC17 TTI7 NA MSGCCS) 139% DEF FREE SPACE 
ce1}) TT16 O MSGCS) 129% OF FREE SPACE 
cc19 TTX2 O MSGCS) 139% OF FREE SPACE 
cc19 SWCH OO MSGC(S) 139% OF FREE SPACE 

CC13 PROG 1 MS6C(S) 9)% OF FREE SPACE 
~->22.37 WAIN (C122 PREMJDINTED 

€CI33 aT COMPLETED 
SP 25585 27 f* SOT INF 

CCI? OF CNCT= O WAITIVS = O 
“->22.38 J°ER YOU ARE CONNES TED TO IOF 


cC}3 BT COMPLETED 
22.39 TT72 DEACTIVATED SY JSER 
* ¢c91 USER/PROJSECT/BILLINGs APPL? 
-->22.39 T1212 TT/TIP2/TI2-PRIG 
* ¢C)2 PASSWORD2?93 


~->22.39 T1172 FF 

22.39 TT12 ACTIVATED FIR PROG ON FER 186% 1 
-->2?2.,47 TIN? €eEDT PROG . 

CC172 PROG 3 MSS5C(S) 73% OF FREE SPACE 
-->22.49 TT32 €x$OT STRING 

C€C98 T1372 ACTIVE FOR 9RIOG STEM? US= TT 


e¢c9 NBLOCK 193/118 IN=EN OUEN 
CC32 OM=24 IMsz5 OF=N 
ccC1) 03 M MS6(S) 199% OF FREE SPACE 


-->22.41 TTI2 Se$3T MAIN PLEASE START PROSCPRIG QUEUE IS FULL) 
-->22.41 TT32 PLEASF START PROGC PROG QUFUE IS FULL) 


~€C93 AT COMPLETED 
-->22.4? OPER *FND OF SESSION IN 5 MINUTES 

CCI3 aT COMPLETED 
22.42 T™I2 HPEALCTIVATED BY USER 
22.44 RT DEACTIVATED RY APPL 
22.44 LNIR DEACTIVATED 

CCIR NETS 

CODR LNA? 

Oe TTOZ/IOLE 


CCI8S LNIZ7 IPLE 

CCIR LNOR YOLE 

CCIB LNIG6 IDLE 

A TTIS/TOLE 

COIS TL COMPLETED 

CC11 LND2 HELD BY SYSTEW,ZREASIN: SHUTDOWN 


1-03 


kh kkkkkkkkkbkhkkhkhkhkk kkk kkkkkhkkkh kkk kkk kkk kkk keke ke kkk kkk kkk tk 
KR RE KR E KER KEK RE KEKEKESTATISTI CS cee reek kkk kk tk kkk thik kkk tk 
kKhkkkkkkkhtkkhtkkkkkkktkk kk kkkkkkhikkkhe kkk kkktkkkkk tk kkh tke kh tkhkk tk kk 


TRML: TTI)2 
———— 


INPUT WESS.: 39907969 
— OUTPUT MESS. 990928 


Nn OUT PUT ERQDIS: 07999) 
a 


total number of retries which 
have been executed by BINS when 
attempting to send data to the 
terminal. 


total number of messages, 
including system messages, 
sent to the terminal. 


total number of messages 
received from the terminal. 


the terminal is identified in one of two ways, namely, 

- by the "terminal name'' specified in the TERMNL command at CNC 
generation, in this case TTO2 

- by **** if the terminal is connected over a switched line in which 
case, the name is not significant because different terminals may 
work one after the other over the same line for the duration of the 
communications seSSione 


The above information appears for each terminal declared at network generatione 
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LINK:iN)2 
INPUT ¥£SS.23)99)439 
et ee 


OUTPUT MESS. 3999928 
ee 
DUTP UT FRR9%S309999) 


total number of retries 
executed by BINS when 
attempting to receive 
data from the line. 


total number of retries 
executed by BTNS when 
attempting to send data 
over the line. 


total number of messages, 
including system messages, 
sent over the line. 


total number of messages 
received from the line. 


name of the line declared in the 
LINE command at CNC generation. 


The above information appears for each line declared at network generation. 
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sc 
RP NAME:<BTNS 
VCAM 
ee a al 


BP SEG SI12E&:932272 
a 


UNIT SIZE3O9I112 
~~ Ne 


JNIT V3299)92) 
ee 


WAX JNEIT W3:299997% 
et i 


maximum number of units 
used in the buffer pool 
during the session. 


number of units in the 
buffer pool declared 
by NBBTBF or NBDABF 
parameters of the 
GENCOM command for BTNS 
or VCAM subsystems, 


size of the buffer unit as 
defined by BTBFSZ or DABFSZ 
parameters of the GENCOM 
command for BINS or VCAM 
subsystems 


size of the buffer pool in bytes. 


3 lines of information are displayed, one line for each buffer pool, 


» SC : Site controller buffer pool internal to BTNS and is auto- 
matically sized by BINS for containing messages sent and 
received by the site controller. 


- BINS : information relates to BINS buffer pool. 


« VCAM : information is displayed if the communications session in- 
volves a VCAM subsystem 
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CORE QUEF 
DISK 3JFFER 


eee number of blocks used during the session in: 


PEAK NB of} {sLocxs Is :390006 


- the core queue segment 


- the disk buffer pool used to access the disk queue 
file. 
The disk buffer pool is automatically sized by CNC 
according to the number of lines and MCS COBOL ap- 
plication programs to be executed simultaneously , 
see MAMNB parameter of the GENCOM command. 


The information above applies specifically to MAM. 


kkk kkk k kkk kh kkk kk kkk kkk kekkkkkkkkhkkkkkkkkhkkkkkkk kk kkk kkk kkk kkk 
kkk kk kkk keh kek kk keke KKKEEKEEEND OF STATIS TUCS ee rekeekkk kk ke kke kkk kkkk kkk 
kkk kkkkkkhhtkkktkhk kk kkk kkk kkk kkk ktkkk ek kkkkkhkikkhkk kk kk kkk kkk k kk 


The following information is 


common to all JOR listings. 


22.44 NETG TERMINATED 
TASK MAIN J=201 P=0) COMPLETED 
CPU 9.984 
ELAPSED 14,102 STACKOV 341 
LINES J LIMIT. NOLIM MISSING SESMENTS 2% 
CARDS Y LIMIT NOLIM BACKING STORE 19535) 


22244237 STEP COMPLETED 


BUFFFR SIZE 


S840 COSTZE 2772 


START 2223732) LIVES ) 
SToP 22244237 CARDS a) 
CPU 0.384 
ELAPSE 14.291 

22244237 RESULT: J98 39 232 
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